hg: lambda/lambda/jdk: 3 new changesets

[Olexandr Demura]

Ropes to the rescue?
http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.14.9450&rep=rep1&type=pdf
http://ahmadsoft.org/ropes/

>> I don't like the class StringJoiner because despite the fact it's a
>> reduce operation,
>> it's implemented as a Fillable, so something eager which will not work
>> as is in the parallel world.
>
>That's where we started -- trying to treat string joining as a reduce.
>But because String is immutable, doing a sequential reduce with string
>concatenation becomes an O(n^2) operation, which is not good.
>
>(Originally we thought that the way to do joining was:
>   stream.interleaveWith(Streams.repeating(", "))
>         .reduce(String::concatenate)
>but the reduce step, which, while pretty, was inefficient.)
>
>The parallel case isn't much better.  Even if you do a number of string
>joins at the leaves of the tree, the top-level combine still has to copy
>all the string content, which loses most of the parallelism.
>
>But you can still do upstream ops in parallel:
>
>  collection.parallel()
>            .filter(...)
>            .map(...)
>            .sorted()
>            .sequential()
>            .into(new StringJoiner(", "));
>
>and all the upstream stuff will happen in parallel.
>
>> I think it's better to add join() on Iterable.
>
>Would like to, but we can't add methods that only apply to specific
>parameterizations.