We encountered similar problems at work trying to wrap I/O up into lazy seq's. The problem is that it is very easy to accidentally hold on to the head of a seq while enumerating it's elements. In addition, we had problems with not closing file descriptors. A common pattern was to open a file, produce a lazy seq of the contents of the file, closing the file when the last element was read. The seq would then be passed off to other parts of the code, which would read some of the elements, and then drop the seq- leaking the open file handle (at least until the gc got around to it).
We finally said "don't use a seq unless you don't mind all the elements being in memory!" and wrote a producer class. The producer class is similar to a normal Java iterator, in that getting the next element updates the state of the object- however maps and filters are applied lazily, and there is an additional close function which says that no more elements need to be produced (allowing for the closing the underlying file descriptor, for example). I disbelieve in golden hammers. Seqs (aka lazy lists) are incredibly useful in a lot of places, and I'm glad that Clojure has them. On the other hand, there are times and uses where seqs are the wrong tool to use. Of course, the same can be said of producers. Brian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
