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

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.


> 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; (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.)

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!