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