Re: [Scheme-reports] Question regarding interaction between new syntax-rules extensions

On Sat, May 25, 2013 at 11:39 PM, Peter Bex <Peter.Bex@x> wrote:

On Sat, May 25, 2013 at 04:04:10PM +0200, Taylan Ulrich B. wrote:
> Peter Bex <Peter.Bex@x> writes:
>
> > [...] what should happen when the underscore is chosen as the ellipsis
> > identifier?
>
> Intuitively I would expect it to work as ellipsis in that case, because
> we're explicitly specifying that, whereas the default meaning is
> implicit. I can't see if draft 9 specifies anything about this, though.

That's what I intuitively thought, as well. And it was easiest to
add it this way to Chicken's syntax-rules implementation :)

The intention is that whatever you specify explicitly overrides

the implicit underscore behavior (a good rule in general).

We made this clear for literal underscores, but overlooked and

left this unspecified when using underscore as the ellipsis.

I think underscore as both the ellipsis and a literal should be an

error. We can let R8RS clarify these two points.

[Note the Chibi implementation is simply ellipsis > literal > wildcard

in all cases.]

> By the way, I wonder why we can't specify an alternative for the
> underscore, while we can specify what to use as <ellipsis>.

The more I think about it, the more I think the underscore wildcard is a
big mistake. It's unneccessary, does not extend cleanly like you pointed
out, and breaks backwards compatibility. But voting has ended, so this
is likely to be kept as-is.

Because underscore doesn't nest I can't think of any reason to override it.

Because underscore as a literal overrides the wildcard behavior, it just

does the right thing in all cases I've ever seen (unlike the R6RS semantics

which broke quite a lot of useful code). It's theoretically possible for an

R5RS macro to break if you're using an underscore both in the pattern and

in the template, but 1) I've not seen such an example personally, 2) it would

be bad style, breaking the existing convention of underscore as "unused",

and 3) the workaround is trivial (just use a different pattern variable).

Alex