In the ClojureScript case, you can do lazy compile time compilation instead, where the predicate call is really a macro that always expands into a predicate call but during compile time can check if the tree needs to be updated. This isn't as lazy as the runtime version but at least groups of extend-pred won't compile unnecessarily.
The only other option I can see is to make the compile step like a hook that is integrated to the build process and runs at the very end. -Brent On Aug 22, 3:12 pm, David Nolen <dnolen.li...@gmail.com> wrote: > On Mon, Aug 22, 2011 at 3:07 PM, Brent Millare <brent.mill...@gmail.com>wrote: > > > > > > > > > > > > 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. > > > If you want, you can be lazy about compilation and only compile right > > before the call to the predicate only if a new predicate has been > > added since the last compilation. Also, we can be smart about how we > > do the cached tree check. After extend-pred is called, it wraps the > > current DAG tree with a compilation step. > > > During the compilation step (made right before the call), the new DAG > > tree is made and replaces the old one. Note that there is no longer a > > check for new predicates. > > > -Brent > > Interesting idea. One possible down side of lazy runtime compilation is that > it makes it more difficult to target ClojureScript. > > 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
