unordered()

[Brian Goetz]

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.)
>
>
>