Re: Grammars for future languages

davids@ICSI.Berkeley.EDU (David Petrie Stoutamire)
Fri, 10 Nov 1995 15:54:08 GMT

          From comp.compilers

Related articles
[6 earlier articles]
Re: Grammars for future languages jaidi@technet.sg (1995-11-09)
Re: Grammars for future languages martelli@cadlab.it (1995-11-04)
Re: Grammars for future languages schinz@guano.alphanet.ch (1995-11-05)
Re: Grammars for future languages ECE@dwaf-hri.pwv.gov.za (John Carter) (1995-11-07)
Re: Grammars for future languages mbbad@s-crim1.daresbury.ac.uk (1995-11-08)
Re: Grammars for future languages szilagyi@szilagyi.mit.edu (1995-11-09)
Re: Grammars for future languages davids@ICSI.Berkeley.EDU (1995-11-10)
Re: Grammars for future languages macrakis@osf.org (1995-11-10)
Re: Grammars for future languages mfinney@inmind.com (1995-11-12)
Re: Grammars for future languages RWARD@math.otago.ac.nz (Roy Ward) (1995-11-13)
Re: Grammars for future languages macrakis@osf.org (1995-11-13)
Re: Grammars for future languages rekers@wi.leidenuniv.nl (1995-11-14)
Re: Grammars for future languages egouriou@CS.UCLA.EDU (Eric Gouriou) (1995-11-16)
[1 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: davids@ICSI.Berkeley.EDU (David Petrie Stoutamire)
Keywords: parse, design
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 <martelli@cadlab.it> 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:


        Expression Equivalent
        ---------- ----------
        a+b a.plus(b)
        a*b a.times(b) (etc.)
        a=b a.is_eq(b)
        a.b := c; a.b(c)
        a[b] a.aget(b)
        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
right.


>[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.


        - Dave
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.