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

On Fri, May 4, 2012 at 3:11 PM, Eli Barzilay <eli at barzilay.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120504/8f6749dc/attachment-0001.html>