[racket-dev] racket/match is broken

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Sat Oct 8 12:34:30 EDT 2011

On Oct 8, 2011, at 12:29 PM, Robby Findler wrote:

> On Sat, Oct 8, 2011 at 11:17 AM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>> 
>> On Oct 5, 2011, at 10:48 PM, Jay McCarthy wrote:
>> 
>>> Okay. I think it is strange, but feel free to do that and revert my
>>> change. Apologies for the confusion.
> 
>> I think you shouldn't apologize here. I am unhappy that match
>> doesn't guarantee order of matching in a list.
>> 
>> Sam should change the implementation not the documentation.
> 
> I'm hoping to eventually use match for redex in order to get some
> performance improvement and I fear that disabling these optimizations
> would be bad news for me there. So I hope that's not what happens
> here.


I doubt that this applies but I am willing to look at 
counter-examples. 


> I don't mind if the ordering of calling the predicates is fixed when
> match cannot prove that the predicates are all safe to be reordered
> (presumably by match keeping a list of known-to-be-safe predicates
> somewhere and perhaps looking at the compile-time info to find struct
> predicates).
> 
> (That would seem to be a straight-forward change, unless I'm missing something.)


That would be fine too. 


> 
>> The entire reason
>> I use lists is that I want left-to-right traversals. If I don't
>> I use 'no order' patterns.
> 
> I don't think the above makes sense. Presumably you use lists when you
> want to *match* from left to right and no order when you don't care
> about the order of *matching the elements in the list*.
> 
> But that's not really relevant for this discussion.


But matching includes calling functions via app. So some no-order
form is the right spec that says "match and you are welcome to call
the functions in no -order too." If you really want to separate these
two ideas, you could do so, too. 









Posted on the dev mailing list.