On Thu, Jan 8, 2009 at 10:20 AM, Rich Hickey <richhic...@gmail.com> wrote: > On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey <richhic...@gmail.com> > I think the real test of non-cached seqs is to swap them in for > regular seqs, rebuild Clojure and some user libs and see what breaks > and why. Then you'll see the dependencies on caching that exist in the > real world. Your purely functional code might not care, other than > perf, but that is not the only user base Clojure and I need to support. > > Rich
I tried to do that, swapping lazy-cons in core.clj to use the commented out code from the lazy-seq macro, but I couldn't get Clojure to build. Clearly something in the bootstrapping code relied on lazy-cons working exactly the way it works. So yes, it is clear that there are currently some dependencies on lazy-cons being cached. What is less clear is whether those depedencies can be easily isolated and rewritten to explicitly use a separate caching version of lazy-cons, leaving the rest of the codebase free to use an uncached variation of lazy-cons by default. I didn't understand the code well enough to find the conflict that was preventing the code from building, so I ended up separating out the uncached variations as a separate library so I could at least experiment within my own code. But I agree that rebuilding Clojure in this way would be very enlightening. Maybe I'll take another stab at it... --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
