home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / misc / 4074 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  14.0 KB

  1. Xref: sparky comp.lang.misc:4074 comp.lang.eiffel:1389 comp.object:4654
  2. Path: sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!news.funet.fi!ajk.tele.fi!funic!sauna.cs.hut.fi!cs.hut.fi!Ari.Huttunen
  3. From: Ari.Huttunen@hut.fi (Ari Huttunen)
  4. Newsgroups: comp.lang.misc,comp.lang.eiffel,comp.object
  5. Subject: Request for feedback on the Sather 1.0 Specification
  6. Message-ID: <ARI.HUTTUNEN.92Dec23235150@cardhu.cs.hut.fi>
  7. Date: 23 Dec 92 23:51:50 GMT
  8. Followup-To: comp.lang.misc
  9. Distribution: inet
  10. Organization: Helsinki University of Technology, Finland
  11. Lines: 317
  12. NNTP-Posting-Host: cardhu.cs.hut.fi
  13.  
  14. Here is a short list of changes between
  15. Sather versions 0.2 and 1.0 that was
  16. mailed on the Sather mailing-list. At the
  17. end are instructions how you can obtain
  18. the precise specification by FTP. 
  19.  
  20. And Merry Christmas to you all!
  21.  
  22.         A.H.
  23.  
  24. -----clip-------clip--------clip-------clip-------
  25.  
  26. From: om@ICSI.Berkeley.EDU (Stephen M. Omohundro)
  27. To: sather@ICSI.Berkeley.EDU
  28. Subject: Request for feedback on the Sather 1.0 Specification
  29.  
  30. Sather version 0.2 has been available for a while now and we have
  31. gotten lots of feedback both from outside users and from internal
  32. projects. Based on this feedback, we have an initial specification for
  33. Sather 1.0, the first "official" version of Sather. It incorporates a
  34. number of new features which are briefly described below. As with
  35. earlier versions, our goal remains to support extremely efficient
  36. computation in the context of powerful abstraction mechanisms. We
  37. would be very interested in feedback on the 1.0 specification document
  38. which is available by anonymous ftp (retrieval instructions are given
  39. at the end of this note). While the implementation is currently
  40. underway, the design is still somewhat flexible. Comments received
  41. before the end of January 1993 are much more likely to have an impact
  42. than later comments. Comments on the design should be sent to
  43. "isather@icsi.berkeley.edu".
  44.  
  45. The document "The Sather 1.0 Specification" is a precise description
  46. of the 1.0 proposal. The following paragraphs informally describe some
  47. of the features which version 1.0 adds to version 0.2. The features
  48. are listed roughly in the order they might be noticed in examining
  49. ordinary code.
  50.  
  51. 1. Declaration during assignment. Variables can now be automatically
  52. declared to have the return type of an expression which is assigned to
  53. them by using the symbol "::=". For example, "a::=5" could be used to
  54. simultaneously declare "a" as an integer and assign the value 5 to it.
  55.  
  56. 2. Extended routine argument syntax. A routine may now specify default
  57. values for its arguments. Routine calls can either specify the
  58. argument values positionally or by name. Any unspecified arguments
  59. take the default value. Routines may have one unnamed argument which
  60. is automatically named "arg" (somewhat analogous to "res" for the
  61. return value).
  62.  
  63. 3. Iters. The feature which will perhaps affect the most code is a new
  64. iteration construct called an "iter". These are a powerful
  65. generalization of a similar construct in CLU. Typical loops (such as
  66. Sather "until" loops) initialize some iteration variables, execute the
  67. body of the loop, increment the variables in some way, and test for
  68. the end of the loop.  A typical example is code to step through the
  69. elements of an array. The code for initializing, incrementing, and
  70. testing the iteration variables is often complex and subject to
  71. "fencepost" errors. It also often relies on the internal details of a
  72. data structure. The same code for doing this is often repeated in many
  73. places. These aspects suggest that this kind of code should be
  74. encapsulated in some way. The Sather 0.2 libraries introduced a number
  75. of "cursor" classes to help with this situation. The iter construct is
  76. a cleaner and easier to use form of encapsulation.  Iters allow the
  77. iteration generation code to be separated from the body of the loop
  78. which uses it and to be placed in the class which has access to the
  79. neccessary information. Iters look much like routines, except that in
  80. addition to returning values, they can also "yield" them.  For
  81. example, the INT class has the iter:
  82.  
  83.    iter up_to(last:INT):INT is
  84.       -- Yield successive integers from `self' up to and including `last'.
  85.    res:=self; until res>last loop yield; res:=res+1 end end;
  86.  
  87. Iters are called from with in "for" loops. For example, to print out
  88. the integers from 10 to 20, one might say:
  89.  
  90.    for j::=10.up_to(20) loop OUT::i(j).nl end
  91.  
  92. The body of the loop is executed each time the iter "yields".  Iters
  93. are particularly useful in conjunction with more complex data
  94. structures. For example the ARRAY{T} class has the iter "elts:T" which
  95. yields the elements in order. For example, here is a routine to sum
  96. the elements in an array:
  97.  
  98.    sum(ARRAY{INT}):INT is 
  99.       for e::=arg.elts loop res:=res+e end end
  100.  
  101. Iters can also indicate that some of their arguments are to be
  102. re-evaluated on each iteration by declaring them to be "hot". ARRAY{T}
  103. defines "set_elts(hot T):T" which first yields an element of the array
  104. and then sets it to the current value of the argument. To set each
  105. element of "a:ARRAY{INT}" to "7" one could say:
  106.  
  107.    for a.set_elts(7) end
  108.  
  109. To double each element of the array one can say:
  110.  
  111.    for e::=a.set_elts(2*e) end
  112.  
  113. "For" loops can step through multiple iters at the same time. For 
  114. example, to copy the elements of "a:ARRAY{INT}" to "b:ARRAY{INT}" you
  115. can say:
  116.  
  117.    for e::=a.elts, b.set_elts(e) end
  118.  
  119. Many other data structures now use iters where they used to use
  120. cursors. For example, trees have iters to yield their nodes in pre,
  121. post, and in order sequence. Much of the matrix and vector library
  122. code now uses iters. This improves the readability and correctness of
  123. the code. It also improves the execution performance because the
  124. compiler can convert iter loops into inlined code using pointer
  125. arithmetic.
  126.  
  127. 4. More flexible basic types. In 1.0 user programs can now define
  128. basic types with a specified number of bits and specified alignment
  129. requirement. This allows one to design classes for special-purpose
  130. machines with new fundamental types. Basic classes can now also have
  131. attributes. This allows, for example, complex numbers to be
  132. represented by basic objects. It also allows arrays whose elements
  133. have structure to be represented by a single chunk of memory. This
  134. makes certain data structures, such as hash tables, more efficient.
  135.  
  136. 5. Statically type safe. Sather 1.0 is statically typesafe in the
  137. sense that it is now impossible for a program which compiles to assign
  138. an object of the wrong type to a variable. This was made possible by
  139. introducing stronger typing rules and by the introduction of the
  140. "typecase" construct which generalizes and replaces reverse
  141. assignment.
  142.  
  143. 6. Bound and unbound routines and iters. Unbound routines are a new
  144. construct which generalizes the "function pointer" construct of
  145. languages like C. Bound routines generalize the "closure" construct of
  146. languages like lisp. A bound routine combines a reference to a routine
  147. in some class with an object of that class using the symbol "&". The
  148. object explicitly holds the state which is only implicit in a closure.
  149. Some applications of this construct include associating functionality
  150. with operations in a window system, associating actions with rules in
  151. a parser, and constructing higher order routines. For example, here is
  152. how bound routines can be used to write a routine which forms the
  153. composition of two argument routines:
  154.  
  155. class COMPOSE{R,S,T} is
  156.    r1:ROUT{R}:S; -- The inner routine.
  157.    r2:ROUT{S}:T; -- The outer routine.
  158.  
  159.    comp_helper(R):T is
  160.       -- Output the effect of `r1' followed by `r2'.
  161.       res:=r2(r1(arg)) end;
  162.  
  163.    comp(r1:ROUT{R}:S, r2:ROUT{S}:T):ROUT{R}:T is
  164.       -- Return the composition of `r1' and `r2'.
  165.       ob::=new; ob.r1:=r1; ob.r2:=r2;
  166.       res:=ob.&comp_helper end
  167. end;
  168.  
  169. The class INT defines "abs:SAME" to compute the absolute value and
  170. "sqrt:SAME" to compute the square root. The routine "sqrt" requires
  171. that its argument be positive, so we might want to compose these
  172. routines. The statement:
  173.  
  174. r::=COMPOSE{INT,INT,INT}::comp(INT::&abs,INT::&sqrt)
  175.  
  176. makes "r" a bound routine of type ROUT{INT}:INT which first forms the
  177. absolute value of its argument and then takes the square root. For
  178. example, "r(-9)" would return 3.
  179.  
  180. Another use appears in the ARRAY{T} class. The routine
  181. "map(ROUT{T}:T)" takes a routine as an argument, and applies it to
  182. each element of the array.  For example, if "a:ARRAY{FLT}" then
  183. "a.map(FLT::&squared)" squares each element, while "a.map(FLT::&sin)"
  184. takes the sine of each element.
  185.  
  186. 7. Abstract classes. Classes which specify abstract interfaces are now
  187. defined separately from other classes (their names still begin with
  188. "$"). The syntax has the form:
  189.  
  190. abstract class $FOO is ... end
  191.  
  192. They may contain "abstract routines" which specify an interface but do
  193. not provide an implementation.
  194.  
  195. 8. No debug keys. Assert statments no longer have an associated
  196. keyword. Boolean constants are typically used to obtain the same
  197. effect when wanted. 
  198.  
  199. 9. Switch -> case. The name "switch" has been changed to "case". 
  200.  
  201. 10. Typecase. Reverse assignments are no longer allowed. Instead, the
  202. "typecase" construct is used to conditionally execute code based on
  203. the type of a variable. This also introduces powerful new ways to use
  204. the type system.
  205.  
  206. 11. Require and Ensure. Routine and iter pre and postconditions are
  207. now made explicit with "require" and "ensure" clauses. 
  208.  
  209. 12. Default type parameters. Parameterized classes may specify default
  210. types for their parameters. This is convenient when there is a common
  211. case which is only rarely changed.
  212.  
  213. 13. Type bounds. Explicit bounds may now be placed on type parameters. 
  214.  
  215. 14. External classes. Instead of the "C" class, the interface to other
  216. languages is now richer. External classes allow a separate Sather
  217. class to be dedicated to each external object file and for the
  218. interface between Sather and other languages to be smoother. 
  219.  
  220. 15. Literal forms. All data structures are now specifiable in a
  221. literal form. This allows the specification of the initial values of
  222. the elements in arrays, for example. It also allows arbitrary data
  223. structures with circular pointers, etc. to be specified. For example,
  224. a simple linked list class might be:
  225.  
  226. class LINK is val:INT; next:LINK end
  227.  
  228. We may describe a circular list with 3 elements by the literal
  229. expression:
  230.  
  231. #1(LINK,1,#(LINK,2,#(LINK,val:3,next:#1)))
  232.  
  233. The inner "#1" is a reference to the outer literal expression which is
  234. labelled "#1". Literals may be used to initialize arrays and other
  235. data structures. 
  236.  
  237. 16. Syntactic sugar. The special symbols such as "+", "-", "*", "<",
  238. "[,]" etc.  are now just syntactic sugar for corresponding routine
  239. calls. Classes may define these routines and so allow the use of the
  240. special syntax on their objects. The sematics of equality test and
  241. object assignment are not changable (though assignment to attributes
  242. is). 
  243.  
  244. 17. Exception handling. Exception handling now uses the type system to
  245. switch on exceptions.
  246.  
  247. 18. While statement. The simple loop construct now may utilize both
  248. "while" and "until". 
  249.  
  250. 19. Integer class parameters. In addition to type parameters,
  251. parameterized classes may now have integer parameters as well. This is
  252. useful for specifying the size of fixed-sized arrays (a new basic
  253. class) and the number of bits in an object. 
  254.  
  255. 20. Define and undefine. The old "alias" and "UNDEFINE" constructs
  256. have been replaced by more uniform "define" and "undefine" clauses. 
  257.  
  258. 21. No routines in constant and shared initialization. Arbitrary
  259. routine calls have been eliminated from constant and shared
  260. initializers. This is possible because of the powerful new literal
  261. forms. This simplifies dependencies between classes and allows the
  262. compiler to leave out more unused code. 
  263.  
  264. 22. Default attribute values. Attributes may now specify default
  265. values. The defaults are used if "new" is not passed explicit values
  266. for the attributes. 
  267.  
  268. 23. Enumerated constants. The syntax for defining constants has been
  269. slightly extended to automatically define ranges of integer constants.
  270. For example,
  271.  
  272. constant a::=5,b,c,d,e,f;
  273.  
  274. is a shorthand for:
  275.  
  276. constant a::=5; constant b::=5+1; constant c::=5+2; 
  277. constant d::=5+3; constant e::=5+4; constant f::=5+5; 
  278.  
  279. 24. SAME. "SELF_TYPE" has been changed to "SAME" for better
  280. readability and easier typing.
  281.  
  282. 25. Builtin types. A number of classes are now part of the language
  283. definition.  This makes for greater portability of programs and allows
  284. for better compiler optimization on the fundamental types. The builtin
  285. types include: ARRAY, BITS, BOOL, CHAR, CLASS_TYPE, FIXED_ARRAY, FLT,
  286. FLTD, FLTE, INT, INTH, INTD, STR, SYS. The new numerical classes are
  287. better integrated with IEEE floating point and ANSI C.
  288.  
  289. 26. Interpreter. The new compiler will support interpreted execution
  290. and dynamic linking of compiled routines. This should speed up the
  291. class design cycle and significantly improve the development
  292. environment. 
  293.  
  294. You may obtain the proposed Sather 1.0 specification by anonymous ftp
  295. as follows:
  296.  
  297. % ftp ftp.icsi.berkeley.edu
  298. Connected to icsic.Berkeley.EDU.
  299. 220 icsi-ftp (icsic.berkeley.edu) FTP server (Version 5.60.l) ready.
  300. Name (icsi-ftp:username): anonymous
  301. 331 Guest login ok, send ident as password.
  302. Password:
  303. 230 Guest login Ok, access restrictions apply.
  304. ftp> binary
  305. 200 Type set to I.
  306. ftp> cd pub/sather
  307. 250 CWD command successful.
  308. ftp> get manual-1.0.ps.Z
  309. 200 PORT command successful.
  310. 150 Opening BINARY mode data connection for manual-1.0.ps.Z (102073 bytes).226 Transfer complete.
  311. local: manual-1.0.ps.Z remote: manual-1.0.ps.Z
  312. 102073 bytes received in 1 seconds (1.6e+02 Kbytes/s)
  313. ftp> quit
  314. 221 Goodbye.
  315. % uncompress manual-1.0.ps.Z
  316. % lpr manual-1.0.ps
  317.  
  318. A compressed version of the TeX "dvi" file is also available for
  319. retrieval (manual-1.0.dvi.Z) for printers with different sized fonts
  320. (eg. 600dpi).
  321.  
  322. Stephen M. Omohundro                               
  323. International Computer Science Institute           Telephone: 510-643-9153
  324. 1947 Center Street, Suite 600                            Fax: 510-643-7684
  325. Berkeley, CA 94704                             Email: om@icsi.berkeley.edu
  326.  
  327. --------clip------clip-------clip--------clip-----
  328.  
  329. ...............................................................................
  330. Ari Huttunen                 
  331.