[racket-dev] racket/match is broken

On 10/06/2011 01:20 PM, Eli Barzilay wrote:
> 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.

Well I'll be darned.

I suppose this shows just how deeply I hold assumptions about order and 
shortcutting.

Neil T