On Fri, May 4, 2012 at 3:11 PM, Eli Barzilay <[email protected]> wrote:
> Just now, Carl Eastlund wrote: > > > > 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. > > That's a bogus analogy. > 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. > 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. Currently, there *are* already two problems: (1) people who want to > define an identifier matcher but can't; 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. > (2) people using `null' in a > pattern and get very confusing behavior. The second is probably more > important -- I've seen students try things like > > (define (flatten l) > (match l > [null null] > [(list null more ...) (flatten more)] > ...)) > > And any time a "well behaved" mechanism leads to that kind of > confusion that make me fumble for an explanation, that suggest a flaw > in the design of that mechanism. (In a similar way to allowing > (define 'x ...) -- and that is a more accurate analogy than the > above.) > 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. If you have a different suggestion for the second problem, that makes > the first a much weaker point. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > --Carl
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
