[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Question regarding interaction between new syntax-rules extensions
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 :)
> "A subpattern followed by <ellipsis> can match zero or more elements of
> the input, unless <ellipsis> appears in the <literal>s, in which case it
> is matched as a literal."
> This sounds to me like (syntax-rules foo (foo) ...) would match `foo'
> literally, because first <ellipsis> is made to be `foo', and then an
> <ellipsis> (a `foo') appears in the <literal>s.
To me it made more sense to let foo be seen as an ellipsis, but it could
really go either way I think. For safety, you could even raise an error
that this kind of madness is not supported.
> I don't know if this is
> the intended meaning; in any case it's a useless use-case(!), so in my
> opinion, leaving it unspecified is as good as forcing it to be an error,
> or making up another specific meaning for it.
Yeah, I agree it should probably stay unspecified.
> Perhaps the formal semantics solve either or both issues; I personally
> have a hard time reading those. :)
> 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.
Scheme-reports mailing list