Email list hosting service & mailing list manager


Re: isn't computation-rules redundant? Andre van Tonder 27 Mar 2004 02:07 UTC

On Fri, 26 Mar 2004 xxxxxx@autodrip.bloodandcoffee.net wrote:

> couple implementations hardwire SYNTAX-RULES into DEFINE-SYNTAX; that
> can easily be fixed, just as easily as introducing a new definition
> form for macros.  What you propose here is _exactly_ what I _already_
> suggested, except that I used the existing DEFINE-SYNTAX.

I know.  Actually, scrap my suggestion.

The more I think about it, the more uncomfortable I am with using
DEFINE-SYNTAX to introduce syntactic computations.  The reason for my
discomfort is that, *unlike* e.g. SYNTAX-RULES and SYNTAX-CASE,
SYNTAX-COMPUTATIONS does not define a syntax transformer.  For example,
when one defines

  (define-syntax-computation foo
    (syntax-computations ()
      ((foo x) (syntax-return x))))

it is *not* the case that occurrences of (foo x) in the source code will
be transformed by the macro expander into x.  This behavior is different
from that of syntax transformers such as syntax-rules and syntax-case.
It is the case that (syntax-run (foo x)) will expand into x, but that is a
different story.

So my point is that since syntactic computations are a different kind of
beast from syntax transformers.  One could perhaps call it a
"meta"-syntax-transformer.  It therefore does *not* seem proper to use
DEFINE-SYNTAX to bind syntactic computations to names.  I therefore
suggest that we keep the binding form distinct, either as
define-syntax-computation or perhaps

   DEFINE-META-SYNTAX

keeping open the possibility of defining other "meta"-transformers
in future.