Tabulators, reducers, etc (original) (raw)
Doug Lea dl at cs.oswego.edu
Mon Dec 31 11:14:26 PST 2012
- Previous message: Tabulators, reducers, etc
- Next message: Tabulators -- a catalog
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/31/12 13:40, Brian Goetz wrote:
You are correct that this is mostly sugar around forEach. But we want to enable the same sort of flexible, composible operation for concurrent accumulations. If the user wants to do a three-level groupBy, writing the Block for this is ugly, and we want users to be able to reuse canned tabulations like groupBy, partition, etc.
If that means a thin layer around forEach (just as now tabulate is a thin layer around reduce), that's fine. If it means we use forEach, but have combinators for constructing the appropriate blocks, that's fine too. That's exactly the discussion I'd like to have surrounding concurrent accumulation.
On the off chance that anyone has forgotten :-) my take is still that whatever this ends up looking like, the best-practices advice will be to use explicit par/seq forEach with explicitly concurrent (or not) concrete destinations for all mutative updates.
-Doug
On 12/31/2012 1:17 PM, Remi Forax wrote: On 12/31/2012 07:08 PM, Brian Goetz wrote:
One option might be: use "reduce" for the purely functional forms, use accumulate/accumulateConcurrent for the others:
T reduce(T zero, BinaryOperator reducer); Optional reduce(BinaryOperator reducer); U reduce(U zero, BiFunction<U, T, U> accumulator, BinaryOperator reducer); R accumulate(Accumulator<T, R> reducer); R accumulate(Supplier seedFactory, BiBlock<R, T> accumulator, BiBlock<R, R> reducer); R accumulateConcurrent(ConcurrentAccumulator<T, R> tabulator); This would let us get rid of the Tabulator abstraction (it is identical to MutableReducer; both get renamed to Accumulator). Separately, with a small crowbar, we could simplify ConcurrentAccumulator down to fitting into existing SAMs, and the top-level abstraction could go away. While the concurrent use case is clearly the odd man out here -- suggesting more work is left to do on this -- the rest of it seems an improvement on what we have now. I would like to move forward with this while we continue to work out the correct set of canned accumulators and the correct way to surface concurrent accumulation. while do you want to surface concurrent accumulator given that we have forEach ?? Rémi
- Previous message: Tabulators, reducers, etc
- Next message: Tabulators -- a catalog
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-experts mailing list