|[6 earlier articles]|
|Re: Grammars for future languages email@example.com (1995-11-09)|
|Re: Grammars for future languages firstname.lastname@example.org (1995-11-04)|
|Re: Grammars for future languages email@example.com (1995-11-05)|
|Re: Grammars for future languages ECE@dwaf-hri.pwv.gov.za (John Carter) (1995-11-07)|
|Re: Grammars for future languages firstname.lastname@example.org (1995-11-08)|
|Re: Grammars for future languages email@example.com (1995-11-09)|
|Re: Grammars for future languages davids@ICSI.Berkeley.EDU (1995-11-10)|
|Re: Grammars for future languages firstname.lastname@example.org (1995-11-10)|
|Re: Grammars for future languages email@example.com (1995-11-12)|
|Re: Grammars for future languages RWARD@math.otago.ac.nz (Roy Ward) (1995-11-13)|
|Re: Grammars for future languages firstname.lastname@example.org (1995-11-13)|
|Re: Grammars for future languages email@example.com (1995-11-14)|
|Re: Grammars for future languages egouriou@CS.UCLA.EDU (Eric Gouriou) (1995-11-16)|
|[1 later articles]|
|From:||davids@ICSI.Berkeley.EDU (David Petrie Stoutamire)|
|Organization:||International Computer Science Institute, Berkeley, CA, U.S.A.|
|References:||95-10-103 95-10-140 95-11-048|
|Date:||Fri, 10 Nov 1995 15:54:08 GMT|
I need to correct a few mistakes here...
Alex Martelli <firstname.lastname@example.org> wrote:
>Sather, a fully object-oriented language (freely available from
>icsi.berkeley.edu), uses this same notion and calls it "syntax
Eg. see "http://www.icsi.berkeley.edu/Sather".
>sugar". It's adopted rather extensively in the language; for
>example, a[b]=c in Sather is defined to be syntax sugar for the
>expression a.aset(b,c) (call of method aset on object a with
>parameters b and c), a=b is sugar for a(b) (call of method a
>on object self with parameter b), etc etc.
There are few typos here. Sather defines things this way:
a*b a.times(b) (etc.)
a.b := c; a.b(c)
a[b,c] a.aget(b,c) (etc.)
a[b] := c; a.aset(b,c);
a[b,c] := d; a.aset(b,c,d); (etc.)
Precedence is defined as expected for arithmetic. This syntax is *not*
redefinable, it is hard-coded. Notice that there deliberately isn't
any way to redefine assignment `:=' or parens `()' etc. This syntax is
intended for conventional use with mathematical types (integers,
floating point, matrix/vector, rationals, etc.), and we discourage its
use with anything else.
The use of syntactic sugar of this sort has been incredibly handy - it
is easy, for instance, to define fully efficient higher-dimension
arrays as ordinary classes without needing special compiler support
other than inlining.
>I'm curious -- is this notion of non-alphanumeric notation
>as systematic syntactic sugar for well-defined alphanumeric
>notation an independent inversion of you and Ousterhout
>(the Father of Sather:-), derived from a common, older
>source, or what...? Other languages using it...?
I think you are confusing John Ousterhout, who was at UC Berkeley and
is now at Sun, with Steve Omohundro, who was at ICSI (in Berkeley) and
now with NEC. Sather tried to borrowed many good ideas from many
places, and we were very aware of other approaches used for arithmetic
syntax in other languages. By no means are we claiming to have
invented sugar for arithmetic, but we will claim that we got it just
>[Ned Irons' IMP72 did something like that over 20 years ago. It used an
>Earley parser so you could use any awful ambiguous syntax you wanted,
>and most people did. -John]
This kind of use is terrible, and exactly the sort of thing we wanted
to disallow by design.
Return to the
Search the comp.compilers archives again.