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

Re: Choose-Your-Own-Ellipsis

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

                            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

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