<div class="gmail_quote">On Fri, May 4, 2012 at 2:52 PM, Eli Barzilay <<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class="im">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. </div>(It's still the same, only the definition of what is a binding position is a bit different.) <div class="im"> > Perhaps have an (id _) form that would allow putting your special > identifiers there. </div><div class="im">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. </div>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. </blockquote></div> 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