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

Re: Choose-Your-Own-Ellipsis

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

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