🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #3906

Request for feedback on the Sather 1.0 Specification

#3906
From: Ari Huttunen
Date: Wed, 23 Dec 1992 23:51
317 lines
14552 bytes
Here is a short list of changes between
Sather versions 0.2 and 1.0 that was
mailed on the Sather mailing-list. At the
end are instructions how you can obtain
the precise specification by FTP. 

And Merry Christmas to you all!

		A.H.

-----clip-------clip--------clip-------clip-------

From: om@ICSI.Berkeley.EDU (Stephen M. Omohundro)
To: sather@ICSI.Berkeley.EDU
Subject: Request for feedback on the Sather 1.0 Specification

Sather version 0.2 has been available for a while now and we have
gotten lots of feedback both from outside users and from internal
projects. Based on this feedback, we have an initial specification for
Sather 1.0, the first "official" version of Sather. It incorporates a
number of new features which are briefly described below. As with
earlier versions, our goal remains to support extremely efficient
computation in the context of powerful abstraction mechanisms. We
would be very interested in feedback on the 1.0 specification document
which is available by anonymous ftp (retrieval instructions are given
at the end of this note). While the implementation is currently
underway, the design is still somewhat flexible. Comments received
before the end of January 1993 are much more likely to have an impact
than later comments. Comments on the design should be sent to
"isather@icsi.berkeley.edu".

The document "The Sather 1.0 Specification" is a precise description
of the 1.0 proposal. The following paragraphs informally describe some
of the features which version 1.0 adds to version 0.2. The features
are listed roughly in the order they might be noticed in examining
ordinary code.

1. Declaration during assignment. Variables can now be automatically
declared to have the return type of an expression which is assigned to
them by using the symbol "::=". For example, "a::=5" could be used to
simultaneously declare "a" as an integer and assign the value 5 to it.

2. Extended routine argument syntax. A routine may now specify default
values for its arguments. Routine calls can either specify the
argument values positionally or by name. Any unspecified arguments
take the default value. Routines may have one unnamed argument which
is automatically named "arg" (somewhat analogous to "res" for the
return value).

3. Iters. The feature which will perhaps affect the most code is a new
iteration construct called an "iter". These are a powerful
generalization of a similar construct in CLU. Typical loops (such as
Sather "until" loops) initialize some iteration variables, execute the
body of the loop, increment the variables in some way, and test for
the end of the loop.  A typical example is code to step through the
elements of an array. The code for initializing, incrementing, and
testing the iteration variables is often complex and subject to
"fencepost" errors. It also often relies on the internal details of a
data structure. The same code for doing this is often repeated in many
places. These aspects suggest that this kind of code should be
encapsulated in some way. The Sather 0.2 libraries introduced a number
of "cursor" classes to help with this situation. The iter construct is
a cleaner and easier to use form of encapsulation.  Iters allow the
iteration generation code to be separated from the body of the loop
which uses it and to be placed in the class which has access to the
neccessary information. Iters look much like routines, except that in
addition to returning values, they can also "yield" them.  For
example, the INT class has the iter:

   iter up_to(last:INT):INT is
      -- Yield successive integers from `self' up to and including `last'.
   res:=self; until res>last loop yield; res:=res+1 end end;

Iters are called from with in "for" loops. For example, to print out
the integers from 10 to 20, one might say:

   for j::=10.up_to(20) loop OUT::i(j).nl end

The body of the loop is executed each time the iter "yields".  Iters
are particularly useful in conjunction with more complex data
structures. For example the ARRAY{T} class has the iter "elts:T" which
yields the elements in order. For example, here is a routine to sum
the elements in an array:

   sum(ARRAY{INT}):INT is 
      for e::=arg.elts loop res:=res+e end end

Iters can also indicate that some of their arguments are to be
re-evaluated on each iteration by declaring them to be "hot". ARRAY{T}
defines "set_elts(hot T):T" which first yields an element of the array
and then sets it to the current value of the argument. To set each
element of "a:ARRAY{INT}" to "7" one could say:

   for a.set_elts(7) end

To double each element of the array one can say:

   for e::=a.set_elts(2*e) end

"For" loops can step through multiple iters at the same time. For 
example, to copy the elements of "a:ARRAY{INT}" to "b:ARRAY{INT}" you
can say:

   for e::=a.elts, b.set_elts(e) end

Many other data structures now use iters where they used to use
cursors. For example, trees have iters to yield their nodes in pre,
post, and in order sequence. Much of the matrix and vector library
code now uses iters. This improves the readability and correctness of
the code. It also improves the execution performance because the
compiler can convert iter loops into inlined code using pointer
arithmetic.

4. More flexible basic types. In 1.0 user programs can now define
basic types with a specified number of bits and specified alignment
requirement. This allows one to design classes for special-purpose
machines with new fundamental types. Basic classes can now also have
attributes. This allows, for example, complex numbers to be
represented by basic objects. It also allows arrays whose elements
have structure to be represented by a single chunk of memory. This
makes certain data structures, such as hash tables, more efficient.

5. Statically type safe. Sather 1.0 is statically typesafe in the
sense that it is now impossible for a program which compiles to assign
an object of the wrong type to a variable. This was made possible by
introducing stronger typing rules and by the introduction of the
"typecase" construct which generalizes and replaces reverse
assignment.

6. Bound and unbound routines and iters. Unbound routines are a new
construct which generalizes the "function pointer" construct of
languages like C. Bound routines generalize the "closure" construct of
languages like lisp. A bound routine combines a reference to a routine
in some class with an object of that class using the symbol "&". The
object explicitly holds the state which is only implicit in a closure.
Some applications of this construct include associating functionality
with operations in a window system, associating actions with rules in
a parser, and constructing higher order routines. For example, here is
how bound routines can be used to write a routine which forms the
composition of two argument routines:

class COMPOSE{R,S,T} is
   r1:ROUT{R}:S; -- The inner routine.
   r2:ROUT{S}:T; -- The outer routine.

   comp_helper(R):T is
      -- Output the effect of `r1' followed by `r2'.
      res:=r2(r1(arg)) end;

   comp(r1:ROUT{R}:S, r2:ROUT{S}:T):ROUT{R}:T is
      -- Return the composition of `r1' and `r2'.
      ob::=new; ob.r1:=r1; ob.r2:=r2;
      res:=ob.&comp_helper end
end;

The class INT defines "abs:SAME" to compute the absolute value and
"sqrt:SAME" to compute the square root. The routine "sqrt" requires
that its argument be positive, so we might want to compose these
routines. The statement:

r::=COMPOSE{INT,INT,INT}::comp(INT::&abs,INT::&sqrt)

makes "r" a bound routine of type ROUT{INT}:INT which first forms the
absolute value of its argument and then takes the square root. For
example, "r(-9)" would return 3.

Another use appears in the ARRAY{T} class. The routine
"map(ROUT{T}:T)" takes a routine as an argument, and applies it to
each element of the array.  For example, if "a:ARRAY{FLT}" then
"a.map(FLT::&squared)" squares each element, while "a.map(FLT::&sin)"
takes the sine of each element.

7. Abstract classes. Classes which specify abstract interfaces are now
defined separately from other classes (their names still begin with
"$"). The syntax has the form:

abstract class $FOO is ... end

They may contain "abstract routines" which specify an interface but do
not provide an implementation.

8. No debug keys. Assert statments no longer have an associated
keyword. Boolean constants are typically used to obtain the same
effect when wanted. 

9. Switch -> case. The name "switch" has been changed to "case". 

10. Typecase. Reverse assignments are no longer allowed. Instead, the
"typecase" construct is used to conditionally execute code based on
the type of a variable. This also introduces powerful new ways to use
the type system.

11. Require and Ensure. Routine and iter pre and postconditions are
now made explicit with "require" and "ensure" clauses. 

12. Default type parameters. Parameterized classes may specify default
types for their parameters. This is convenient when there is a common
case which is only rarely changed.

13. Type bounds. Explicit bounds may now be placed on type parameters. 

14. External classes. Instead of the "C" class, the interface to other
languages is now richer. External classes allow a separate Sather
class to be dedicated to each external object file and for the
interface between Sather and other languages to be smoother. 

15. Literal forms. All data structures are now specifiable in a
literal form. This allows the specification of the initial values of
the elements in arrays, for example. It also allows arbitrary data
structures with circular pointers, etc. to be specified. For example,
a simple linked list class might be:

class LINK is val:INT; next:LINK end

We may describe a circular list with 3 elements by the literal
expression:

#1(LINK,1,#(LINK,2,#(LINK,val:3,next:#1)))

The inner "#1" is a reference to the outer literal expression which is
labelled "#1". Literals may be used to initialize arrays and other
data structures. 

16. Syntactic sugar. The special symbols such as "+", "-", "*", "<",
"[,]" etc.  are now just syntactic sugar for corresponding routine
calls. Classes may define these routines and so allow the use of the
special syntax on their objects. The sematics of equality test and
object assignment are not changable (though assignment to attributes
is). 

17. Exception handling. Exception handling now uses the type system to
switch on exceptions.

18. While statement. The simple loop construct now may utilize both
"while" and "until". 

19. Integer class parameters. In addition to type parameters,
parameterized classes may now have integer parameters as well. This is
useful for specifying the size of fixed-sized arrays (a new basic
class) and the number of bits in an object. 

20. Define and undefine. The old "alias" and "UNDEFINE" constructs
have been replaced by more uniform "define" and "undefine" clauses. 

21. No routines in constant and shared initialization. Arbitrary
routine calls have been eliminated from constant and shared
initializers. This is possible because of the powerful new literal
forms. This simplifies dependencies between classes and allows the
compiler to leave out more unused code. 

22. Default attribute values. Attributes may now specify default
values. The defaults are used if "new" is not passed explicit values
for the attributes. 

23. Enumerated constants. The syntax for defining constants has been
slightly extended to automatically define ranges of integer constants.
For example,

constant a::=5,b,c,d,e,f;

is a shorthand for:

constant a::=5; constant b::=5+1; constant c::=5+2; 
constant d::=5+3; constant e::=5+4; constant f::=5+5; 

24. SAME. "SELF_TYPE" has been changed to "SAME" for better
readability and easier typing.

25. Builtin types. A number of classes are now part of the language
definition.  This makes for greater portability of programs and allows
for better compiler optimization on the fundamental types. The builtin
types include: ARRAY, BITS, BOOL, CHAR, CLASS_TYPE, FIXED_ARRAY, FLT,
FLTD, FLTE, INT, INTH, INTD, STR, SYS. The new numerical classes are
better integrated with IEEE floating point and ANSI C.

26. Interpreter. The new compiler will support interpreted execution
and dynamic linking of compiled routines. This should speed up the
class design cycle and significantly improve the development
environment. 

You may obtain the proposed Sather 1.0 specification by anonymous ftp
as follows:

% ftp ftp.icsi.berkeley.edu
Connected to icsic.Berkeley.EDU.
220 icsi-ftp (icsic.berkeley.edu) FTP server (Version 5.60.l) ready.
Name (icsi-ftp:username): anonymous
331 Guest login ok, send ident as password.
Password:
230 Guest login Ok, access restrictions apply.
ftp> binary
200 Type set to I.
ftp> cd pub/sather
250 CWD command successful.
ftp> get manual-1.0.ps.Z
200 PORT command successful.
150 Opening BINARY mode data connection for manual-1.0.ps.Z (102073 bytes).226 Transfer complete.
local: manual-1.0.ps.Z remote: manual-1.0.ps.Z
102073 bytes received in 1 seconds (1.6e+02 Kbytes/s)
ftp> quit
221 Goodbye.
% uncompress manual-1.0.ps.Z
% lpr manual-1.0.ps

A compressed version of the TeX "dvi" file is also available for
retrieval (manual-1.0.dvi.Z) for printers with different sized fonts
(eg. 600dpi).

Stephen M. Omohundro                               
International Computer Science Institute           Telephone: 510-643-9153
1947 Center Street, Suite 600                            Fax: 510-643-7684
Berkeley, CA 94704                             Email: om@icsi.berkeley.edu
 
--------clip------clip-------clip--------clip-----

...............................................................................
Ari Huttunen				 
Technical Details
Message-ID: <ARI.HUTTUNEN.92Dec23235150@cardhu.cs.hut.fi>
Path: arc1-ca.pugleaf.net!sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!news.funet.fi!ajk.tele.fi!funic!sauna.cs.hut.fi!cs.hut.fi!Ari.Huttunen

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!news.funet.fi!ajk.tele.fi!funic!sauna.cs.hut.fi!cs.hut.fi!Ari.Huttunen
From: Ari.Huttunen@hut.fi (Ari Huttunen)
Newsgroups: comp.lang.misc,comp.lang.eiffel,comp.object
Subject: Request for feedback on the Sather 1.0 Specification
Message-ID: <ARI.HUTTUNEN.92Dec23235150@cardhu.cs.hut.fi>
Date: 23 Dec 92 23:51:50 GMT
Followup-To: comp.lang.misc
Distribution: inet
Organization: Helsinki University of Technology, Finland
Lines: 317
NNTP-Posting-Host: cardhu.cs.hut.fi