The alternative to using eval and large code generation that I've seen is to use the compiled tree of closures approach used by CL-PPCRE. If the JVM is smart enough, it may do the inlining for you on the hot code.
http://en.wikibooks.org/wiki/Common_Lisp/External_libraries/CL-PPCRE#Regular_Expressions_as_Trees_and_Closures http://xach.livejournal.com/131456.html?thread=226944 http://gigamonkeys.wordpress.com/2007/07/27/compiling-queries-without-eval/ I agree, benchmarks, experience, and just plain old time will be needed. -Brent On Aug 21, 11:47 pm, David Nolen <dnolen.li...@gmail.com> wrote: > On Sun, Aug 21, 2011 at 11:27 PM, Brent Millare > <brent.mill...@gmail.com>wrote: > > > I have a question about the presentation. > > > You mention that you can't achieve the same dispatching performance in > > the open case compared to the closed space. > > I meant to say that the problem is hard. No completely unsolvable. > > > In my imaginary implementation, extend-pred takes the predicate label, > > the pattern, and the code to be executed (note its code, not a > > function, so you lose the ability to make closures). Each time extend- > > pred is run, a new dispatch tree is compiled with the code to be > > executed integrated into the tree. (This would be done by saving (and > > updating) the code and patterns in a data structure that gets parsed > > and generates code that is the match macro wrapped into a function.) > > It's certainly a possibility. I haven't ruled it out yet. > > I'm mostly concerned with explosive code generation. match by taking the > decision tree approach already favors performance over code size. There are > patterns that are exponential in the amount of code they generate. > Fortunately Maranget did some measurements with real world patterns - code > size for decision trees built with good heuristics were never more than > 1.5-2X the size of their backtracking counterparts. > > For pattern matching code size is a one time cost. For predicate dispatch, > that's a lot of code to generated, since every new predicate case will > produce an entirely new tree. But perhaps people won't care that much. Only > time and experience reports will tell. > > David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
