>> try
>> (def x #(iterate inc 1))
>> (take 1 (drop 1000000000 (x))
>>
>> if you do not want to blow up the memory.
>
> I wonder if an uncached lazy seq variant that cannot hold onto its
> head would be useful to have in core?

I would argue that such a feature wouldn't be very useful. Let's
consider three cases where you might think that an uncached,
extra-lazy seq would be useful.


Case #1

As in the example above, you are really only going to use the seq
once, but Clojure is foolishly holding onto the head longer than
necessary, thus using up a lot of memory.

The only reason we have this problem above is that we foolishly put
this seq, that we were only going to use once, into a global variable.
Global variables should be avoided almost always, especially for
something that will only be used once. We could have done the
following and had no problem.

(let [x (iterate inc 1)]
    (take 1 (drop 1000000000 x)))

That is because Clojure recognizes that x will never again be used
after the drop operation.


Case #2

Okay, maybe we do need to use the seq twice, and it's so large that it
would exhaust all our memory if we ever held the whole thing in
memory. So we want to recalculate the thing twice rather than storing
it all in memory at once. Well, if we are really operating on that
much data, it probably takes a long time to do the calculations as
well. Are we okay with doing all that time-consuming work twice?
Probably better to find a way to calculate both results in one
traversal of the seq in order to reduce computation time.


Case #3

Okay, so it turned out that we really, really couldn't find a way to
calculate both results in one traversal of the seq. It got very
complicated, and we couldn't find any way to get what we needed other
than traversing the enormous seq twice. Fortunately, Laurent has shown
us how to get our extra-lazy seq by adding a # and a couple parens to
our code. Even adding a language feature for this one unusual case,
I'm not sure we could do much better than that.


Summary: This problem we are looking at, is not a problem at all.

-- 
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

Reply via email to