Into (original) (raw)

Brian Goetz brian.goetz at oracle.com
Sun Dec 23 07:33:18 PST 2012

It is sort of a variant of what I've been suggesting, though not quite going as far as serialForEach/parallelForEach. In my view the modes that need to be explicitly chosen between are

reduce/functional/associative/order-sensitive vs forEach/mutative/commutative/order-insensitive

(This distinction only makes a difference in the parallel case, so it is slightly different from the forEach/forEachParallel distinction, but in a similar spirit of "less mind reading.")

On 12/23/2012 9:35 AM, Doug Lea wrote:

On 12/23/12 07:02, Doug Lea wrote:

Your asking people to take car about the concurrency in their code instead of letting the pipeline taking care of that. Only for mutative updates, for which they will need to take the same care in any choice of seq vs par for any use of forEach. So there is nothing much special/interesting about this. The main idea is to be uniform about how mutative constructions are less fluent/streamy-looking than functional usages. (To continue to re-open old wounds :-) For extra Bondage&Discipline/friendly-guidance, we could always re-choose to separately support forEach and parallelForEach methods and get rid of implicit moding for forEach. Implicit moding can never hurt you in this sense for the functional/stateless operations. There are still several other stateful ones that would require some similar separation though. Which might be a variant of what Brian was suggesting a few days ago? -Doug

More information about the lambda-libs-spec-experts mailing list