[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isn't computation-rules redundant?

This page is part of the web mail archives of SRFI 53 from before July 7th, 2015. The new archives for SRFI 53 contain all messages, not just those from before July 7th, 2015.



On Fri, 26 Mar 2004 campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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.