On Fri, May 4, 2012 at 3:11 PM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>></span> wrote:<br><div class="gmail_quote"><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">Just now, Carl Eastlund wrote:<br> ><br> > It's not a question of how many there are, or who knows about them. <br> > Providing your own "if" does not prevent others from shadowing "if"<br> > with let or any other binding form. In a large enough project, lots<br> > of names can get imported from lots of sources. The nice thing<br> > about well-behaved macros is that you don't need to keep all of them<br> > in mind at all times when deciding what names to bind locally. <br> > Having match expanders that cannot be shadowed by match variables<br> > turns match into an ill-behaved macro, in a very similar way to how<br> > let behaves in unhygienic macros.<br> <br> </div>That's a bogus analogy.<br></blockquote><div><br>In both cases, authors of certain local binding forms must be careful not to use names chosen by other bindings in an enclosing scope. I view this as a bad thing. That was the whole of my analogy; in many other ways the two situations do not correspond.<br> </div><div class="im"><br> > Any time a new mechanism only works as proposed if it's used for<br> > "*very* few" cases, that suggests a flaw with the mechanism. If we<br> > add id expanders for match, let's design them so they can be used<br> > frequently without causing problems.<br> <br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Currently, there *are* already two problems: (1) people who want to<br> define an identifier matcher but can't;</blockquote><div><br>That's a missing feature, and one in high demand, but personally I'd rather go without a feature than break an often-relied-upon feature of binding positions. Better than either tradeoff is to find an implementation for the feature that doesn't break anything else. Your proposal thus far is to completely ignore the breakage. For instance, you referred to the one fix proposed so far as "overkill", despite it being simple and direct.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> (2) people using `null' in a<br> pattern and get very confusing behavior. The second is probably more<br> important -- I've seen students try things like<br> <br> (define (flatten l)<br> (match l<br> [null null]<br> [(list null more ...) (flatten more)]<br> ...)) <br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> And any time a "well behaved" mechanism leads to that kind of<br> confusion that make me fumble for an explanation, that suggest a flaw<br> in the design of that mechanism. (In a similar way to allowing<br> (define 'x ...) -- and that is a more accurate analogy than the<br> above.)<br></blockquote><div><br>Perhaps we need a different match form for students, much like the other special cases in student languages. I can see how students would want to have null work differently from other names, because you don't want to teach every detail of how scope interacts with match. In the "professional" Racket language, however, I want to be able to shadow names freely.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> If you have a different suggestion for the second problem, that makes<br> the first a much weaker point.<br> <div class="HOEnZb"><div class="h5"><br> --<br> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:<br> <a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a> Maze is Life!<br></div></div></blockquote><div><br>--Carl <br></div></div>