🚀 go-pugleaf

tmb@arolla.idiap.ch (Thomas M. Breuel) wrote:

> In article <RICHARD.92Oct21123440@ml.harlqn.co.uk>
> richard@harlqn.co.uk (Richard Brooksby) writes:
> 
>    tmb@arolla.idiap.ch (Thomas M. Breuel) wrote some stuff about
>    LISP syntax for ML and how it would make syntactic extensions easier.
> 
>    You want to extend the language and make the parser extensible in
>    order to add new derived forms.  Lisp-like syntax doesn't really
>    make this easier to do if one is to maintain a strong phase
>    distinction.
> 
> I don't want to have to make the parser extensible in order to add
> "new derived forms". That's precisely my point.

*Flash* I see!  (Probably.)

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.  I'm
not sure how regular a meta-syntax of Standard ML would be for the
purposes of such extensions.  Any ideas?  I have seen some work in
this area in a Calculus of Constructions language somewhere.  Can
anyone come up with a reference of brief details?

Are you advocating the exposure of the underlying data structure to
the programmer?  If so, all my objections still apply.
---
Richard Brooksby <richard@harlqn.co.uk>
ML Project / Symbolic Processing Division / Harlequin
+44 223 872522 ext 50