Tabulators, reducers, etc

[Doug Lea]

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<T> reducer);
>>>>      Optional<T> reduce(BinaryOperator<T> reducer);
>>>>      <U> U reduce(U zero, BiFunction<U, T, U> accumulator,
>>>> BinaryOperator<U> reducer);
>>>>
>>>>      <R> R accumulate(Accumulator<T, R> reducer);
>>>>      <R> R accumulate(Supplier<R> seedFactory,
>>>>                       BiBlock<R, T> accumulator,
>>>>                       BiBlock<R, R> reducer);
>>>>
>>>>      <R> 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
>>
>