backwardation

[Paul Phillips]

The challenges of backward compat...

Who can dream up a way for me to combine Iterable and Traversable in a
backward (source)-compatible way?

Your challenge:

In Traversable, foreach is abstract
in Iterable, foreach is concrete, iterator is abstract
Iterable extends Traversable

So that means there's code out there like this:

new Traversable[Int] { def foreach[U](f: Int => U) = () }

And there's code out there like this:

new Iterable[Int] { def iterator = 1 to 10 iterator }

And there's code out there like this:

def f(xs: Traversable[Int]) = 10; f(Iterable(5)) ; f(Traversable(5))

I fear it cannot be done without some kind of magic wand (macros?
macros can do anything, right?)

- Traversable must have exactly one abstract method (foreach)
- Iterable must have exactly one as well (iterator)
- Iterable must extend Traversable (or must it? Maybe this is our in)

One might think OK, so we leave a "Traversable skeleton" in place, big
deal. Well it is a big deal, because the traits pass their type
constructor around with abandon and you can't fudge it, e.g.

trait GenIterable[+A]
extends GenIterableLike[A, GenIterable[A]]
with GenTraversableOnce[A]
with GenericIterableTemplate[A, GenIterable]

A Traversable skeleton won't stay quiet, he'll insist on a bunch of
supporting traits and all the goodness starts evaporating.

[Paul Phillips]

Also, I can recommend blending core collections traits as a way to see
really interesting error messages.

[scalacfork] trait Iterable[+A] extends Traversable[A] {
[scalacfork] ^
[scalacfork] /scala/trunk/src/library/scala/collection/GenIterable.scala:31:
error: polymorphic expression cannot be instantiated to expected type;
[scalacfork] found : [A(in method newBuilder)(in method
newBuilder)(in method newBuilder)(in method newBuilder)(in method
newBuilder)(in method newBuilder)(in method newBuilder)(in method
newBuilder)]scala.collection.mutable.Builder[A(in method
newBuilder)(in method newBuilder)(in method newBuilder)(in method
newBuilder)(in method newBuilder)(in method newBuilder)(in method
newBuilder)(in method newBuilder),Iterable[A(in method newBuilder)(in
method newBuilder)(in method newBuilder)(in method newBuilder)(in
method newBuilder)(in method newBuilder)(in method newBuilder)(in
method newBuilder)]]
[scalacfork] required: scala.collection.mutable.Builder[A(in method
newBuilder)(in method newBuilder)(in method newBuilder)(in method
newBuilder)(in method newBuilder)(in method newBuilder)(in method
newBuilder)(in method newBuilder),scala.collection.GenIterable[A(in
method newBuilder)(in method newBuilder)(in method newBuilder)(in
method newBuilder)(in method newBuilder)(in method newBuilder)(in
method newBuilder)(in method newBuilder)]]

[Grzegorz Kossakowski]

On 16 December 2011 23:41, Paul Phillips <pa...@improving.org> wrote:

I fear it cannot be done without some kind of magic wand (macros?
macros can do anything, right?)

Is it only me or whenever I go to read on some scala stuff I end up reading about macros the-holy-thing that will save us all from all suffering in the Scala land? In some other thread I've read macros will bring flying cars too.

--
Grzegorz

[Paul Phillips]

On Fri, Dec 16, 2011 at 2:53 PM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> Is it only me or whenever I go to read on some scala stuff I end up reading
> about macros the-holy-thing that will save us all from all suffering in the
> Scala land? In some other thread I've read macros will bring flying cars
> too.

BURN THE HERETIC

[Daniel Sobral]

Speaking of which, will there be a SIP about this, or will it be fait
accompli? I entertain strong reservations about this idea, and I'd
rather be able to discuss it before so much effort is spent that it
becomes easier to leave the changes in than take them out.

--
Daniel C. Sobral

I travel to the future all the time.

[Paul Phillips]

On Fri, Dec 16, 2011 at 3:23 PM, Daniel Sobral <dcso...@gmail.com> wrote:
> Speaking of which, will there be a SIP about this, or will it be fait
> accompli? I entertain strong reservations about this idea, and I'd
> rather be able to discuss it before so much effort is spent that it
> becomes easier to leave the changes in than take them out.

I'm just exploring. I think either the gains will speak for
themselves or they won't.

[Josh Suereth]

I'm a fan of splitting external vs. Internal iterator abstraction so one does not inherit the other...

[Simon Ochsenreither]

Hi,

How much would it break source-wise and how easy would be a fix?
Would it be a problem for people who wrote their own collection class and use Traversable only implicitly/only those who refer to Traversable explicitly/normal users?
How many changes would be necessary to get the code to compile again?
Maybe we can live withe some breakage ...

Thanks and bye,


Simon