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] |
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)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.