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.