Spliterator

[Brian Goetz]

>> There's no reason it can't
>> be spec'ed
>> and generalized to more than one subsequent split (and if an
>> implementation
>> doesn't want to promise that, return 1.)
>
> Sorry, I don't get this.
> Is the intent to be able to bypass a call to isSplittable
> across multiple calls to split?

That's not the goal, though that is an effect.

> That is, do you need to replace:
>
>    while (s.isSplittable() && /* ... other conditions ...*/)
>      ... s.split...
>
> with:
>
>     for (int splits = s.getNaturalSlits();...) {
>       if (!/* ... other conditions ...*/)
>          break;
>       ... s.split...
>     }
>
> Or is there some other reason I'm not seeing?

We use split() to build a tree of splits; this is mirrored by a tree of 
FJTs.  I use this information to determine when split() is creating a 
new level of the tree, and when it is creating a new sibling at the same 
level.

                 T firstChild = makeChild(spliterator.split());
                 setPendingCount(naturalSplits);
                 numChildren = naturalSplits + 1;
                 children = firstChild;
                 T curChild = firstChild;
                 for (int i=naturalSplits-1; i >= 0; i--) {
                     T newChild = makeChild((i > 0) ? 
spliterator.split() : spliterator);
                     curChild.nextSibling = newChild;
                     curChild = newChild;
                 }
                 for (T child=children.nextSibling; child != null; 
child=child.nextSibling)
                     child.fork();

                 firstChild.compute();

> (Or is getNaturalSplits a remnant from previous designs in
> split was not mutative and you could ask for multiple splits at once?)

You could think of it as an alternate way to do that, yes.

The point is: I see value to the possibility of arranging spliterators 
in other than a binary tree.

> To be useful, the spec must imply that if isSplittable returns false
> the caller should not call split.

Agreed.

> But we cannot say such things
> in an interface spec. The constraint that I listed makes it clear
> that looping calls to split that do not check isSplittable
> could infinitely loop.

Right.  But if we s/isSplittable == false/getNaturalSplits == 0/, why 
don't we get that same promise?

I don't disagree with anything you're saying except the implicit 
assumption that no one would ever want to build other than a binary tree 
of splits.  (And I don't understand what the split arity has to do with 
the other spec issue, and why they're being intertwined?)