On Mon, Oct 29, 2012 at 10:00 PM, Wolodja Wentland <[email protected]> wrote:
> I find this behaviour quite unfortunate because I now have to explicitly test
> for nil? and ensure consistent behaviour. This inconsistency violates the
> principle of least-surprise and I am not sure if the current behaviour is
> intentional or merely an unfortunate implementation detail.
fold wont work in parallel on list/seqs/etc, so if you're trying to
get the improved threading performance out of fold/fold-into-vec
you'll have to supply a vector.
(vec nil) => []
Then;
(->> data
vec
(r/map inc)
fold-into-vec)
Unfortunately if you "vec" a vector, it'll actually do the work so you may want;
(defn ensure-vec [xs]
"Ensure's that the value provided is a vector"
(if (= (type xs) clojure.lang.PersistentVector)
xs
(vec xs)))
> P.S. Would it be possible to have something like fold-into-vec in
> clojure.reducers?
Don't forget fold-into-map and fold-into-map-with, but both of those
will likely require a better merge/merge-with function for maps. :(
P.S.
As soon as I can find a moment, I can provide a JVM friendly library
for reducing over mmap'ed text files as well.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
