Thank you all and especially @James. That is exactly what I'm missing.
Thanks again for help.
On Wednesday, September 24, 2014 5:51:09 PM UTC+2, James Reeves wrote:
Reducers primarily have two benefits:
1. You don't need to create intermediate seqs
2. You can use them to perform a parallel
Resulting function is passed to reduction function as an recipe, how to process
the data. Collections implements CollReduce protocol. When you call reduce
function it will delegate the work to concrete implementation of the protocol.
--
You received this message because you are subscribed to
When the collection is reducing itself, it is going to create a sequence
and call cons, conj or something like.
If this is true, then I'm not sure what reducers is bringing to the table.
Because according to what I read, by using reducers, map/filter functions
aren't going to create and allocate
To elaborate more,
I know that with reducers, map for example isn't going to create the
resulting sequence by using cons. That is clear to me.
But, if the collections is going to call cons while reducing itself, then
I'm not sure what is the benefit of reducers (besides it makes sense and
makes
Reducers primarily have two benefits:
1. You don't need to create intermediate seqs
2. You can use them to perform a parallel fold
When you use clojure.core/map, it creates a lazy seq. When you use
clojure.core.reducers/map, it returns a small reified object that
implements CollReduce.
Perhaps
I think you are referring to this
article:
http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html
What Rich means with a collection to reduce itself is using the internal
reduce implementation tied to the collection. E. g. using reduce with
Hi,
I spent a considerable time trying to understand reducers. I got the
concept of how the map/filter function will return a function and it is not
going to iterate over a sequence and it is not going to create a new
sequence.
The missing part though, who is creating the sequence?
They say a
