[racket-dev] racket/match is broken

From: Eli Barzilay (eli at barzilay.org)
Date: Thu Oct 6 15:20:17 EDT 2011

Just now, Neil Toronto wrote:
> On 10/06/2011 12:28 PM, Prabhakar Ragde wrote:
> > On 10/6/11 2:12 PM, Eli Barzilay wrote:
> >
> >> Sam is talking about building the ASTs *while* matching, which is
> >> what Jay was trying to do with uses of `app'. I think that a
> >> teaching context is in particular one where such a thing doesn't
> >> fit -- it obscures the distinction between the side the sexpr
> >> goes into, and the side where an AST comes out.
> >
> > Okay, I see the distinction, and I apologize for not having fully
> > understood Jay's example. I agree that this obscurity is
> > hazardous. I think, though, that I have always assumed
> > left-to-right matching, though I may never have constructed
> > anything that would break if it didn't happen. --PR
> 
> I think most people expect branching constructs like 'match' to make
> in-order (left-to-right/depth-first), short-cutting decisions.
> Additionally, the cases themselves do this. So I think the fact that
> the patterns don't is very surprising.

IIRC, the cases are also reordered to optimize tests -- and that's an
even more important optimization:

  -> (define (list?? x) (printf "list-checking ~s\n" x) (list? x))
  -> (define (one?? x) (printf "one-checking ~s\n" x) (eq? 1 x))
  -> (match '(1 (2) 3)
       [(list (? one??) 2 3) 1]
       [(list _ (? list??) _) 2]
       [(list (? one??) 20 30) 3])
  list-checking (2)
  2

and after Jay broke it, you get

  one-checking 1
  list-checking (2)
  2

IMO it is perfectly fine to require that stuff used in `match'
patterns is side-effect-free, and therefore cachable and reorderable.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!


Posted on the dev mailing list.