Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.misc Subject: Re: scheme [Re: What does an anti-perl look like] Message-ID: Date: 28 Jun 91 08:10:20 GMT References: <2928.UUL1.3#5129@willett.pgh.pa.us> Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 42 In-Reply-To: dwp@willett.pgh.pa.us's message of 27 Jun 91 20:45:31 GMT Nntp-Posting-Host: cdollin.hpl.hp.com Doug Philips says: Indeed. As someone else has already pointed out, Lisp syntax allows programs/code to be data, and visa versa. Of course, if you come from a background in Algol-like languages, you may not see how that could be valuable. If you think that orthogonality between syntax and semantics is useful, you would like lisp syntax. Can we dispose of this myth for once and for all? It's not ``Lisp syntax'' that allows code-as-data; it's because there's a canonical representation for program texts as a supported datatype. In Lisp, the supported datatype happens to be lists, and the mapping twixt source and representation is at least translucent. But there's no reason an ``Algol-like'' language (whatever that means in 1991; are C, Ada, ML, Pop11, or Scheme Algol-like? Answers on a postcard please ...) shouldn't provide a suitable data-type and representation scheme. For example ``here's one I prepared earlier'': in my Pop-like language Pepper, I plan to include a construct such as ``<$ Expr $>'' to mean ``the parse tree associated with Expr''. There will be operations on parse trees, such as gluing them together and taking them apart, or generating code from them. (The present compiler uses lists for parse trees - surprise! - but the post-bootstrap compiler will have a more compact representation engineered to its needs.) So it's not the (concrete) syntax of Lisp that gives code-as-data; it's the act of making the parse tree *available*. [Incidentally, rather than an anti-quoting syntax within the quote brackets, I am thinking of making the quote take a left operand, viz, the names to be taken as meta-variables inside the quotation, thus: (x) <$ f(x) $> would denote the parse tree for an application whose function-part is f and whose argument part is the expression in the variable x. Any comments on this idea?] -- Regards, Chris ``GC's should take less than 0.1 second'' Dollin.