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
51st item to identify the end of the sequence. So it has to hold onto the
head of the tail sequence. No matter what your (take 50 t) does. This
combined with the fact, that you hold onto the head of t with the (count t)
after the (count d).
drop does obviously not look ahead due to the wrapping lazy-seq. This can
be easily verified in the repl. Please consider, that upon realisation via
seq, the first element of the remaining output has to be realised anyway!
user> (def s (drop 2 (map #(doto % prn) (list 1 2 3 4 5))))
#'user/s
user> (def t (seq s))
1
2
3
#'user/t
user>
Again that notwithstanding drop could be optimised to save a wrapping
lazy-seq object in the case we call drop with 0. But that again is an
optimisation, not a bug. An implementation could look like this:
(defn drop+
[n coll]
(if (pos? n)
(lazy-seq (drop+ (dec n) (rest coll)))
coll))
In general lookahead is not debatable. A sequence function which looks
further ahead then absolutely necessary to perform its function is broken.
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
