On 04.02.2009, at 14:03, Rich Hickey wrote:
> 1) Resource management in lazy contexts > 2) Memory consumption in recursive lazy contexts (the filter retains > skipped range issue) > 3) Full laziness in I/O and other side-effect contexts, and for ease > of understanding > 4) Performance/elegance > 3 - I thought the demand for full laziness was greater than it > apparently is, given the lack of feedback on these features. I'd say the most immediate need is for I/O, including network access. I have a couple of other applications in mind, for example computational pipellines, but those will take a while to implement. Perhaps Clojure is too young for much demand to appar on this list. > 4 - Right now there is a plain tradeoff of elegance for performance, > and I'm not satisfied with that. What is the main reason for the performance loss in new-style lazy sequences? Memory allocation? Creation of the closures that represent the state of data generation? Would it be possible to have new-style lazy seqs plus a generator interface as for streams? That could take the form of a function that takes a generator and presents it as a fully sequence. Generator functions that manage their own state would serve two purposes: (1) an efficient alternative to recursive sequence-producing functions for optimizing critical pieces of code, and (2) a straightforward way to use code in Java or another JVM language to define a stream of data. Konrad. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
