On Oct 8, 2011, at 12:29 PM, Robby Findler wrote: > On Sat, Oct 8, 2011 at 11:17 AM, Matthias Felleisen > <matth...@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. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
