[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: moving on
> From: Taylor Campbell <campbell@xxxxxxxxxxxx>
> 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).
> My recommendation is keep it simple:
> (... ...)
> (... ... ...)
> (... ... ... ...)
> etc, to match existing practice.
What existing practice are you talking about? Where is this
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.