backwardation

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

On 16 December 2011 23:41, Paul Phillips <paulp [at] improving [dot] 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

On Fri, Dec 16, 2011 at 2:53 PM, Grzegorz Kossakowski
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

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.

On Fri, Dec 16, 2011 at 20:41, Paul Phillips wrote:
> 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.

On Fri, Dec 16, 2011 at 3:23 PM, Daniel Sobral 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.

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

On Dec 16, 2011 6:28 PM, "Paul Phillips" <paulp [at] improving [dot] org> wrote:

On Fri, Dec 16, 2011 at 3:23 PM, Daniel Sobral <dcsobral [at] gmail [dot] 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.

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