Of course not, lazy is opt-in in CL, that wouldn't be idiomatic. Besides, the semi-lazy approach of Clojure's pmap (allocate futures consecutively) doesn't see

Of course not, lazy is opt-in in CL, that wouldn't be idiomatic. Besides, the semi-lazy approach of Clojure's pmap (allocate futures consecutively) doesn't seem to convince everyone: https://stackoverflow.com/questions/2103599/better-alternative-to-pmap-in-clojure-for-parallelizing-moderately-inexpensive-f https://stackoverflow.com/questions/2103599/better-alternati... https://www.reddit.com/r/Clojure/comments/20lxmv/just_what_is_the_overhead_of_pmap/ https://www.reddit.com/r/Clojure/comments/20lxmv/just_what_i... On the one hand, when you want to parallelize, you are delegating tasks to workers and you want them to do what they need, independently of you. But on the other hand, laziness introduce a dependency from you, because workers cannot produce a result before they are sure you really need it. This basically slows down parallelization and that's why I am not sure Clojure's pmap is a good general solution. Note that Clojure Reducers, mentioned here in Zombie Metaphysics (ppmap: http://www.braveclojure.com/zombie-metaphysics http://www.braveclojure.com/zombie-metaphysics) and documented at https://clojure.org/reference/reducers https://clojure.org/reference/reducers, use strict sequences. Laziness is great when you need it, but when you don't you shouldn't have to pay for it. http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html http://clojure.com/blog/2012/05/08/reducers-a-library-and-mo...