[racket-dev] [plt-scheme] Bug or misuse? match-expander ids not properly working (patch)

On Fri, May 4, 2012 at 2:52 PM, Eli Barzilay <eli at barzilay.org> wrote:

> 20 minutes ago, J. Ian Johnson wrote:
> > That behavior would be really spooky to me. I would expect binding
> > positions to not depend on any environmental information.
>
> (It's still the same, only the definition of what is a binding
> position is a bit different.)
>
>
> > Perhaps have an (id _) form that would allow putting your special
> > identifiers there.
>
> And, Carl Eastlund wrote:
> > If we add some kind of id expanders for match patterns, we need to
> > add a way for pattern variables to shadow these names if the author
> > really wants to.   Otherwise, every id expander defined eats up more
> > namespace that match variables cannot bind.
> >
> > We already have this issue with _ and ..., but at least that's a
> > known set of constant size.
>
> Some (id <name>) be possible, but definitely an overkill for the
> purpose of `null' etc.  Like I said, there should be *very* few of
> them in `#lang racket'.  The rest are for your own convenience, as in
> Madoka's case (and in a few cases I ran into).  I could obviously
> define and provide a match expander for `x' in my library that you'll
> want to use -- but that's the same as providing you with my own `if'.
>
> The bottom line is that if this change is done, then such an `id' form
> would not be necessary -- either it's for obvious names (the few that
> are done in the library), or for names that you defined which you're
> supposed to know about.
>

It's not a question of how many there are, or who knows about them.
Providing your own "if" does not prevent others from shadowing "if" with
let or any other binding form.  In a large enough project, lots of names
can get imported from lots of sources.  The nice thing about well-behaved
macros is that you don't need to keep all of them in mind at all times when
deciding what names to bind locally.  Having match expanders that cannot be
shadowed by match variables turns match into an ill-behaved macro, in a
very similar way to how let behaves in unhygienic macros.

Any time a new mechanism only works as proposed if it's used for "*very*
few" cases, that suggests a flaw with the mechanism.  If we add id
expanders for match, let's design them so they can be used frequently
without causing problems.

--Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120504/5be1ef53/attachment.html>