🚀 go-pugleaf

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.