This page is part of the web mail archives of SRFI 46 from before July 7th, 2015. The new archives for SRFI 46 contain all messages, not just those from before July 7th, 2015.
On Wednesday, Oct 15, 2003, at 18:07 US/Eastern, Alabaster Petrofsky wrote:
Your code is too fragmentary for me to understand what you're trying to do. You talk about expanding into a SYNTAX-RULES form, but in r5rs, any macro use must ultimately expand into an expression, definition, or BEGIN form.
Hmm. I can't find any mention of this in R5RS. Perhaps you meant that because the RHS of a DEFINE-SYNTAX may only be a transformer, SYNTAX-RULES is the only kind of transformer, and transformers are disjoint from expressions -- which is what macro _uses_ fall under --. Nevertheless, I'm a little annoyed I can't do this. (See the next section.)
I guess what you're trying to write is
something like this:
(define-syntax define-msyntax-rules
(syntax-rules ()
((define-msyntax-rules name ?ellipsis ?literals
((?ignored . ?pattern)
(?macro . ?args))
...)
(define-syntax name
(syntax-rules ?ellipsis ?literals
((?ignored (k ?ellipsis) . ?pattern)
(?macro (k ?ellipsis) . ?args))
...)))))
...which would make me have a need to define LET-MSYNTAX-RULES and LETREC-MSYNTAX-RULES as well, and anyone who wanted to use MSYNTAX-RULES anywhere else would need to write their own foo-MSYNTAX-RULES. This is rather irritating, but I'm almost afraid to consider putting a fix of what I mentioned above in this SRFI -- do something about macro uses being used as transformers --, as it would undoubtedly generate a flame war somehow or other due to potential issues with phase separation and such. But not changing this will _really_ impede some macros I've written (which I wrote when I didn't think of expressions not being allowed as transformers, and which I tested in implementations that _did_ allow expressions as the RHS of DEFINE-SYNTAX).
Am I missing some macro magic here, is there a problem with choose- your-own-ellipsis, or should the implicit ... stuff be thrown away? The last option would break lots of macros, and it would look rather ugly to me, but I can't think of a better way to solve this.If we specified that syntax-rules from now on requires an ellipsis argument, then that would of course break the entire existing body of syntax-rules macros.
Eh, only a minor inconvenience!
However, if you specify that define-msyntax-rules requires an ellipsis
argument, I don't think there's any body of define-msyntax-rules code
out there to be worried about breaking.
Nevertheless, if you want define-msyntax-rules's ellipsis argument to
be optional, with the implicit (and essentially non-hygienic) choice
of "..." when it is missing, you could do this:
(define-syntax define-msyntax-rules
(syntax-rules ::: ()
((define-msyntax-rules name (?literal :::)
((?ignored . ?pattern)
(?macro . ?args))
:::)
(define-syntax name
(syntax-rules (?literal :::)
((?ignored (k ...) . ?pattern)
(?macro (k ...) . ?args))
:::)))
((define-msyntax-rules name ?ellipsis ?literals
((?ignored . ?pattern)
(?macro . ?args))
:::)
(define-syntax name
(syntax-rules ?ellipsis ?literals
((?ignored (k ?ellipsis) . ?pattern)
(?macro (k ?ellipsis) . ?args))
:::)))))
DUH! I can't believe I didn't think of that. (Although I'd have preferred not to have to rewrite the final expansion twice.) But I guess it's a good thing I didn't, because it brings up the issue I mentioned in the first section of my response in this email.
What are some thoughts on non-linear patterns and guardsI think they are probably incompatible with the title of the SRFI, "Basic SYNTAX-RULES Extensions".
Well, the title has already changed once, when I added tail patterns a few minutes after I initially submitted the document. Of course, I don't think non-linear patterns are really that complex; since it's possible to write a SYNTAX=? that compares two syntax items (?) _without_ non-linear patterns,[*] which isn't _that_ complicated, and SYNTAX=? is all that you need _for_ non-linear patterns, it seems like a fairly basic extension. Guards, of course, are much more complex, and I didn't think anyone would like them, but I decided to throw the idea out there nevertheless. [*] http://www.bloodandcoffee.net/campbell/code/syntax-equal.scm Part of the 'syntax-lib.scm' that I'm compiling (a very early and incomplete version of which can be found by substituting 'lib' for 'equal' in that URI), which I shall rewrite soon to hide the CPS details with monads (once I finish improving Andre's monadic CPS macro stuff, and add some stuff further even than the DO# macro for making CPS macros simpler and easier).