On Sat, Oct 8, 2011 at 12:45 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > On Oct 8, 2011, at 1:43 PM, Robby Findler wrote: > > > I assume you mean the context > > (define number? > (let ((old number?)) > (lambda (any) > (displayln `(I am testing ,any)) > (old any))))
Of course I didn't. What are you trying to say here? That our macro system cannot compare bindings? That you write bad code like that and expect it to perform well? Something else? > >> This expression: >> >> (match x >> [`(lambda (,x) ,e) ...] >> [(? number?) ...] >> [`(,e1 ,e2) ...]) >> >> >> has, by my count, 7 opportunities to do things in different orders (6 >> cons cells can be matched car-position first or cdr-position first and >> the order of which clause to try first can be moved around in at least >> one way) and at least one of them seems profitable (merging the cons? >> test from the first and second lines). I'd have to try some timings >> and get more careful to say if that one is actually profitable or if >> there are others but it is, in my mind, definitely at the "worth >> trying" level, especially because there has been published work that >> gets a 30% speedup on match-intensive things. >> >> I think that the restriction I suggest above will rule out only (what >> I would consider) strange match expressions, in practice. At least >> based on my experience. > > But yes, even w/ my redefinition you get some freedom. > > What I meant was: for the original example (Jay's), you'd get L2R. Oh, yes. Definitely. >> In my mind, a more difficult question is just how much speed we're getting. > > Speed is a dangerous game. Speed kills. Ask anyone. Robby _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
