unordered()

[Joe Bowbeer]

Btw, this form compiles in jdk8lambda-b69:

    Stream<Integer> is = Streams.iterate(0, i -> i + 1).map(i -> (Integer)
(i * i)).limit(25);

--Joe


On Mon, Dec 24, 2012 at 6:29 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Right.  This is caused by the interaction of "IntFunction extends
> Function" and the overload resolution rules.  Fixed by severing the
> extension relationship between IntFunction and Function.
>
>
> On 12/24/2012 8:01 PM, Joe Bowbeer wrote:
>
>> Continuing with Uncle Bob's FP snippet:
>>
>>      (take 25 (squares-of (integers)))
>>
>> I can code this in jdk8lambda-b69 as:
>>
>>      Function<Integer, Integer> square = (Integer i) -> i * i;
>>      Stream<Integer> is = Streams.iterate(0, i -> i +
>> 1).map(square).limit(25);
>>
>>
>> First, *note* that the following simplification won't compile because
>> the RHS creates an IntStream:
>>
>>      Stream<Integer> is = Streams.iterate(0, i -> i + 1).map((Integer i)
>> -> i * i).limit(25);
>>
>> This is a bug, right?
>>
>>
>> Now something about unordered()..
>>
>> When I add parallel() before the map() and print the result, I find that
>> the into() form creates ordered results no matter where I insert
>> unordered() in the pipeline, whereas forEach() already produces
>> unordered results.
>>
>> 1. Always ordered, regardless of unordered()
>>
>>      out.print(is.map(Object::**toString).into(new StringJoiner(" ")));
>>
>>      => 0 1 4 9 ... 441 484 529 576
>>
>> 2. Naturally unordered
>>
>>      is.forEach(i -> out.print(i + " "));
>>
>>      => 0 529 576 441 ... 9 16 1 4
>>
>> Seems weird.
>>
>> -Joe
>>
>>
>>
>> On Fri, Dec 21, 2012 at 2:13 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com**>> wrote:
>>
>>     So, the move to a more explicit choice of merging or concurrent
>>     tabulation also reduces (heh) the need for unordered(), though it
>>     does not eliminate it completely.  (Limit, cancelation, and
>>     duplicate removal all have optimized versions if encounter order is
>>     not significant.)
>>
>>     Kevin pointed out that .unordered() is pretty easy to miss, and
>>     people will not know that they don't know about it.  One possible is
>>     to make it more explicit at one end of the pipeline or the other
>>     (the only operation that is order-injecting is sorted(), and
>>     presumably if you are sorting you really care about encounter order
>>     for the downstream ops, otherwise the sort was a waste of time.)
>>
>>     The proposed tabulator / reducer stuff makes the order-sensitivity
>>     clear at the tail end, which is a good place to put it -- the user
>>     should know whether a reduce or a forEach is what they want -- if
>>     not the user, who?  (Only the user knows whether he cares about
>>     order or not, and knows whether his combination functions are
>>     commutative or not.)  The other less-ignorable place to put an
>>     ordering opt-out is at the head; we could make things more clear
>>     with adding
>>
>>        .parallelUnorderedStream()
>>     alongside
>>        .stream()
>>     and
>>        .parallelStream()
>>
>>     The obvious implementation of parallelUnorderdStream is:
>>
>>          default Stream<E> parallelStream() {
>>              return stream().unordered();
>>          }
>>
>>     which is also the most efficient place to put the .unordered (at the
>>     head.)
>>
>>
>>
>>