The sequence returned from the filter would need to be rescanned to get the nth element, but the filtering itself should only need to happen when the "next" element in the sequence is sought.
For cases such as the one you describe, I think it's common to fully realize the sequence into a vector, e.g. (vec (filter ...)) to avoid rescanning. On Nov 20, 5:00 am, bOR_ <boris.sch...@gmail.com> wrote: > Hi all, > > Just ran into a small gotcha: I had an atom which contained a lazyseq > (e.g. (filter males world)). Later on I would be repeatedly calling > random elements from this atom, using clojure contrib rand-elt. That > was surprisingly slow. I figured out that count was the culprit. > Apparently, the lazyseq atom stayed a lazyseq atom (immutability), and > each time I called for a random element, count had to do the whole > filtering to figure out 'count'. > > Is there any way that I can get a warning printed out that would let > me know when I am doing something stupid like this? for example: > (repeatedly evaluating identical full lazy sequence @world)? -- 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
