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).