On Sat, May 25, 2013 at 11:39 PM, Peter Bex <[email protected]> wrote:
> On Sat, May 25, 2013 at 04:04:10PM +0200, Taylan Ulrich B. wrote: > > Peter Bex <[email protected]> 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
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
