Re: Grammars for future languages

szilagyi@szilagyi.mit.edu (Peter Szilagyi)
Thu, 9 Nov 1995 20:51:02 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: Grammars for future languages timd@Starbase.NeoSoft.COM (1995-10-30)
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)
[2 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: szilagyi@szilagyi.mit.edu (Peter Szilagyi)
Summary: I loved Clu. It was much better than Cats.
Keywords: parse, design
Organization: MIT <just a luser student>
References: 95-10-103 95-10-140 95-11-048
Date: Thu, 9 Nov 1995 20:51:02 GMT

Alex Martelli <martelli@cadlab.it> wrote:
>"Roy Ward" <RWARD@math.otago.ac.nz> writes:
> ...
>>what I have done with ReWrite to maintain _some_ consistency of notation,
>>is that I have defined operation such as plus, not, etc. and effectively
>>defined the infix forms as being equivalent to the prefix ones, so
>
>>a+b is _exactly_ equivalent to plus[a,b]
>>!a is _exactly_ equivalent to not[a],
>
>>so I can deal with these functions in the same way as any others.


[...]


>Sather, a fully object-oriented language (freely available from
>icsi.berkeley.edu), uses this same notion and calls it "syntax
>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.
>
>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...?


Clu, I believe, fits in that geneology somewhere, but I know not
where. I offer only the following. In Clu,


a[b] := c; => T(a)$store(a, b, c);


where T(a) is the type of a, and the T operator is not part of the
language. (Clu is module-oriented rather than object-oriented.) I
programmed in Clu for our undergraduate Software Engineering lab, and
this syntactic sugar really did its job. Compact notation, clean
semantics, you can have your cake and eat it, too. (Actually, I'm a
Scheme junkie, so this talk of "syntax" is rather foreign to me. :)


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


I am, as I am wont to be, ignorant. Clu is (supposedly) a pedagogical
language, defined in {\it Abstraction and Specification in Program
Development}, Liskov and Guttag, copyright 1985, MIT Press, out of
print. (I don't recall when it was defined, but this IMP72 thingy is
probably much older.) Now that I've bothered everyone with something
they already knew and wasted hundreds, if not thousands, of dollars...


--szilagyi (Peter Szilagyi, Asynchrony Boy, szilagyi@mit.edu)
--


Post a followup to this message

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