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

Re: Choose-Your-Own-Ellipsis



Hmm.  I just found a problem with this 'choose-your-own-ellipsis'
device.

In improving Andre van Tonder's monadic CPS macro stuff, I wrote an
MSYNTAX-RULES.  When this discussion came up, I changed it to work
with the 'choose-your-own-ellipsis' thing (with the first option --
optionally specify it before the list of literals --).  MSYNTAX-RULES
is defined to expand

(msyntax-rules ellipsis ()
  ((ignored . pattern) (macro . args))
  <real ellipsis, i.e. any number of the clauses>)

to

(syntax-rules ellipsis ()
  ((ignored (k ellipsis) . pattern)
   ;; Allow for multiple continuations, for possible branches.
   (macro (k ellipsis) . pattern)))

and expand

(msyntax-rules () clause <real ellipsis>)

to

(msyntax-rules ... () clause <real ellipsis>)

But I found this problem: should the user not specify the ellipsis,
and let it default to ..., how will MSYNTAX-RULES deal with it?  I
can't have one of the clauses in the macro be

    ((_ ?literals
        ((?ignored . ?pattern) (?macro . ?args))
        :::) ;; we specified ::: for the ellipsis of the definition of
             ;; the MSYNTAX-RULES macro
     (msyntax-rules ... ?literals
       ((?ignored . ?pattern) (?macro . ?args))
       :::))

because then the ... that might be in ?PATTERN or ?ARGS would be
hygienically renamed.  I could, of course, use Al* Petrofsky's hack to
substitute an identifier in a syntax object(? list? expression? what
do you call those things in SYNTAX-RULES?  'Syntax object' is what you
call the first-class Scheme values that represent syntactic things in
SYNTAX-CASE, but that doesn't seem right for SYNTAX-RULES, where it's
not first-class Scheme values that I'm talking about), but that would
not let anything else generate MSYNTAX-RULES macros (as with the
LOOP-WHILE problem of Al* Petrofsky's LOOP example).

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.  Opinions
or comments, anyone?