[clean-list] "code is data" and Clean

[RT Happe]

On Thu, 27 Feb 2003, Mark Phillips wrote:

> One of the key advantages of LISP (as far as I can tell) is
> that its relatively simple (yet powerful) syntax means that
> LISP _code_ looks just like the _data_ it works on.  Because

It's appropriate to look at the components of this advantage.  Some of
these may be grafted on a modern functional language, or the effect may be
achieved with other means.

(0) a simple syntax for textual representations of data
(1) a corresponding and well-supported built-in data-type (trees,
    basically)
(2) i/o procedures translating the (textual) external into the (concrete)
    internal representation and v.v.

(3) source code in the ``data-syntax'' from above
(4) parse-trees represented --as far as the programmer is concerned-- by
    the concrete data-type from above

(5) programmable syntax-extensions -- macros transforming the parse-tree
    of the input form with the full force of the programming language

Items (0,1,2) are extremely useful, giving the principal advantage of XML
without the pain.  And they aren't even incompatible with modernity,
although Clean's type system would complicate things a bit.  This is
mainly a question of library design.  (A prefab parser construction kit
would help with (2).)

Items (3,4) ease meta-programming:  writing partial evaluators, debuggers,
etc.  But that can be achieved with data abstraction (and perhaps less
convenience), too, without exposing the concrete syntax of the language or
the concrete data-type of the parse-tree.  The logic language Goedel went
that way.

Item (5) enables syntactic abstraction.  Macros are used to create special
forms with a special evaluation rule (there's less need for that in a lazy
language) and in general to embed problem-specific ``little languages''
into the host programming language, i.e. Lisp.  This may be achieved with
<input pattern> --> <output template> transformation rules (in the spirit
of Scheme's SYNTAX-RULES) rather than with hand-coded expanders, but it
will complicate the compilation process anyway.  (I don't believe that
macros preclude global program analysis, though.)

rthappe