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

Re: moving on

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

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.