On Sat, Oct 8, 2011 at 11:34 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > 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.
One has been discussed in this thread. I think Sam promised to look into seeing how well it applies to our implementation. > >> 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. > Good. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
