full interop b/w Iterable and java.lang.Iterable

[gavinking]

To my mind, the biggest remaining point of discomfort with Java interop is the fact that a Ceylon for can't iterate a Java collection, and a Java for can't iterate a Ceylon Iterable. So I've put some thought into this today and come up with what looks like a reasonable solution. First, we add the following interface to ceylon.language:

shared sealed interface Loopable<T> {
    shared Iterator<T> iterator();
}

Now, our existing Iterable<T,N> would inherit Loopable<T>.

The backend should:

• replace all references to Loopable with java.lang.Iterable,
• replace all references to Iterator with java.lang.Iterator, and
• do some special stuff for any concrete class which implements our Iterator interface:

Given:

class XIter() satisfies Iterator<X> {
    iterator() => whatever();
}

The backend would produce the following code:

class XIter implements java.util.Iterator<X>, ceylon.language.Iterator<X> {
    private static final Object nil$$$ = new Object();
    private X next$$$ = nil$$$;
    public java.lang.Object next$() {
        return whatever();
    }
    public boolean hasNext() {
        if (next$$$==nil$$$) {
            next$$$ = next$();
        }
        return next$$$!=finished_.getFinished();
    }
    public X next() {
        if (next$$$==nil$$$) {
            return next$();
        }
        else if (next$$$==finished_.getFinished()) {
            next$$$ = null;
            throw new NoSuchElementException();
        }
        else {
            X result = (X) next$$$;
            next$$$ = null;
            return result;
        }
    }
}

Finally, we would replace all calls to Iterator.next() with calls to the following clever utility function:

public <X> java.lang.Object next(Iterator<? extends X> it) {
    if (it instanceof ceylon.language.Iterator) {
        return ((ceylon.language.Iterator<? extends X>) it).next$();
    }
    else {
        return it.hasNext() ? it.next() : finished_.getFinished();
    }
}

WDYT? I don't see any real holes in this. The worse thing about it is the addition of the Loopable interface. But that might even eventually turn out to be useful in some other contexts. And a trivial sealed SMI is not really hurting anything.

[gavinking]

P.S. we might be able to take the same approach with Comparable.

[tombentley]

• I think something like this would be really nice in terms of interop.
• Your XIter class implements Iterator but has an iterator() method. You meant next(). And I assume we just throw UnsupportedOperationException for XIter.remove().
• In your utility next() function did you mean to call next$() (you wrote next()) in the ceylon.language.Iterator branch? In that case it would need to be a hidden method declared on c.l.Iterator, and not merely on subclasses.
• My only concern is the overhead of the utility function. I'm sure a good jvm will just inline it and speculatively optimize away whichever branch is unused (if either) at a given use site. But on jvms without powerful optimizations there could be a perf impact.
• If it resulted in a worthwhile perf improvement, when we knew the Iterator was a Ceylon class we could generate a better performing loop, avoiding the call to Util.next().
• I wonder if we could interest, say, @lucaswerkmeister in having a go at this?

[tombentley]

Java's Iterable<T> is invariant in T (specifically it declares Iterator<T> iterator() rather than Iterator<? extends T> iterator()), but Loopable<T> needs to be out T if it's to serve as a supertype of Ceylon's Iterable.

[tombentley]

It would still be legal to write:

Loopable l = nothing;
value done = l.iterator().next() is Finished;

Since the Ceylon Iterator gets erased to j.u.Iterator we ought to translate that as

l.iterator().$next()

(because we mean Ceylon's next()), but j.u.Iterator doesn't have such a method.

[gavinking]

Java's Iterable<T> is invariant in T (specifically it declares Iterator<T> iterator() rather than Iterator<? extends T> iterator()), but Loopable<T> needs to be out T if it's to serve as a supertype of Ceylon's Iterable.

Oh, oops, that's annoying. It might be OK, since Loopable is going to be erased anyway.

[gavinking]

It would still be legal to write:

@tombentley note that I say above:

Finally, we would replace all calls to Iterator.next() with calls to the following clever utility function:

[gavinking]

So in light of that, the following solution might be better than the one above. Given:

class MyIterable() satisfies Iterable<String> {
    iterator() => MyIterator();
}

We generate:

class MyIterable() implements ceylon.language.Iterable<String>, java.lang.Iterable<String> {
     public final ceylon.language.Iterable<? extends String> iterator$() { return MyIterator(); }
     public final java.lang.Iterable<String> iterator() { return JavaIterator(iterator$()); }
}

And we transform all calls to iterator() to iterator$().

[gavinking]

This is not for 1.1.5, since it would require a break to binary compatibility. Rescheduling to 1.2.