Indeed you're right, the drop lazy-seq prevents the lookahead.
Thanks Meikel for the thoughtful response!
On Tuesday, October 25, 2016 at 2:36:26 AM UTC-4, Meikel Brandmeyer
(kotarak) wrote:
>
> In fact, (doall (take (count t) t)) actually realises t completely. But
> not because of the doall o
However, the drop+ does not stop in case the input sequence is exhausted.
So more waste there...
--
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 moder
In fact, (doall (take (count t) t)) actually realises t completely. But not
because of the doall or take, but because of the count. The problem is not
take, it's the take-while of split-with, which is the trouble. You know
that the input is 50 items long. take-while does not. It has to check the
Certainly the problem is the realizing the tail sequence of the split-with
before the head sequence, and take shouldn't be trying to solve that. But I
guess I would have thought that (doall (take (count t) t)) would have
realized all of t so the head could be released.
Indeed, the take* formulatio
I think this is not a bug in take, but an unfortunate constellation of
laziness.
The solution you propose is basically making take looking one step ahead,
which is not take's business. It could be actually quite dangerous to do so
in case take's n was carefully calculated based on some external
Hi all:
I think I encountered a problem in the clojure.core/take produces lazy
sequences, and I wanted to run it by some folks to confirm it was indeed a
bug.
In a nutshell, clojure.core/take produces lazy sequences in a way such that
(take
(count t) t) will always retain the head of its bas
