🚀 go-pugleaf

In article <RICHARD.92Oct27125430@ml.harlqn.co.uk> richard@harlqn.co.uk (Richard Brooksby) writes:

   We're talking about different things, I think.  You are advocating
   LISP _syntax_ because it means that language extensions don't have to
   modify the parser _algorithm_ because all such extensions conform to a
   simple format.  I'm talking about using LISP _data_structures_ to
   represent the abstract syntax for the purposes of writing functions
   _in_ML_ which manipulate that syntax in the manner of LISP macros.

   In which case, I agree with your point.  A simple and regular
   meta-syntax such as that of LISP S-expressions makes writing what
   amounts to an extensible parser trivial.  This is a Good Thing.

Yes, exactly.

   I'm not sure how regular a meta-syntax of Standard ML would be for
   the purposes of such extensions.  Any ideas?

Well, there are some tricky issues related to pattern matching and
currying. I have some ideas, but it will require a little
experimentation to see how well they work.

   Are you advocating the exposure of the underlying data structure to
   the programmer?  If so, all my objections still apply.

Simply for adding new syntax to the language (e.g., new looping
constructs or constructs like "delay"), I think most people would
prefer not to have to deal with the underlying data structures.
Something analogous to EXTEND-SYNTAX might be sufficient.

Additionally, some standard for representing the AST and for
representing the typed lambda calculus intermediate might be useful to
encourage experimentation with program transformations and
optimization that cannot be expressed in terms of macros alone.

					Thomas.