> From: Taylor Campbell <xxxxxx@evdev.ath.cx>

> It seems that there is a lot more debate about SYNTAX-RIASTRADH to
> come, and I'm not sure if this SRFI has a draft lifetime long enough
> to potentially wait for it.  I'm against CYOE, now; it adds a kludge
> that SYNTAX-RIASTRADH is specifically designed to defend.

What kludginess are you talking about?  Your concern is that the
addition of an optional positional argument makes the calling
convention too hairy, right?  I can go along with that assessment,
although I think the hairiness of (syntax-rules <ellipsis>? <literals>
<rule>+) is actually just shy of being too hairy (and is equihairy
with (let <name>? <bindings> <body-elt>+), which seems to work just
fine in practice).

But the calling convention is a trivial issue compared to the
functionality of Choose-Your-Own-Ellipsis.  The choice is the thing.
I thought people agreed that hygienically binding your identifier of
choice to the role of the ellipsis is more flexible and less kludgy
than (... ...).  As I said in the message in which I proposed the
idea, it can work with whatever calling convention you want to
specify: positional or keyword.

I don't understand why you are still lumping together under the name
"syntax-riastradh" two ideas of wildly disparate radicalness:
unhygienic identifier insertion (radical -- requires more
experimentation and experience before SRFI-dom) and a keyword-tagged
argument list (not so radical).

Bear writes:

> My recommendation is keep it simple:
>
> ...
> (... ...)
> (... ... ...)
> (... ... ... ...)
>
> etc, to match existing practice.

What existing practice are you talking about?  Where is this
implemented?

Please, either choose something new and superior (CYOE), or go with
what Chez Scheme and Macros-That-Work implemented over a decade ago:
(... <template>) expands just like <template>, but with ... having no
special meaning within the <template>.  This means nested uses can be
(... (... ...)), although more commonly you do something like
(... (syntax-rules () ((m) (... ...)))).  This feature enables (as
would CYOE) powerful things like transformer-macro-blocks.scm (see
October 19 post) for which plain old (... ...) does not suffice.

-al