Re: Choose-Your-Own-Ellipsis Taylor Campbell 17 Oct 2003 21:45 UTC
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 guards > > I 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).