representing language for macros

[hopkins@kaleida.com (Don Hopkins)]

>> Why is it bad to require a "data-like" representation of the syntactic
>> elements of the language?  This works quite well in lisp, no?
>
>It works so well in Lisp because Lisp is so simple.  Classical Lisp syntax
>has two non-terminals (atoms and numbers) and one terminal (list cells), and
>the mapping between data and program structure is so direct that one doesn't
>even think about it.
>
>For macros in a language like Self that has real syntax, one has to take a
>position as to how the macro arguments should be parsed.  Should they be
>parsed as expressions?  If so, macros just become an efficiency hack,
>because they can't do anything that ordinary messages can't do.  If not,
>then presumably something in the macro definition has to specify this ... in
>which case we're back to the much more serious problem of deciding how macro
>definitions are scoped and when they should be expanded, a problem which I
>think is quite sufficient to sink the whole concept for Self.
>
>                                                L. Peter Deutsch

I think one problem is that Self syntax sucks. (I never saw the point to
the Smalltalk syntax, and the programming idioms that fall out of it.)
ScriptX has parse trees, that inherit from collections, so they're as easy
to use as "append tree leaf" or "tree[1]". A bit different from lisp
s-expressions, since ScriptX parse trees subclass regular collections and
add behavior like knowing how to compile into bytecode, and state like
leafs with name and module references. The parser is a separate object
that translates byte streams into parse trees, to hide the actual syntax(s)
of the language from syntaxless parse trees.

        -Don