[2.8] Ordering vs. Ordered and back-incompatibility of TreeSet

There's an implicit Ordering[Int] in scala.Ordering.

--j

2009/9/17 Grzegorz Kossakowski <grek@tuffmail.com>

Hello,

I decided to try to compile Gimd[1] with latest snapshot of Scala 2.8 and found that migration won't be that
straightforward.

One of the biggest obstacles is back-incompatibility of TreeSet[T] that cannot be constructed out of T <: Ordered elements.

Let me show what I mean:
Welcome to Scala version 2.8.0.r0-b20090916214543 (OpenJDK Server VM, Java 1.6.0_0).
Type in expressions to have them evaluated.
Type :help for more information.

scala> case class A(n: Int) extends Ordered[A] {
    | def compare(that: A) = n compare that.n
    | }
defined class A

scala> import scala.collection.immutable.Tree

scala> import scala.collection.immutable.TreeSet
import scala.collection.immutable.TreeSet

scala> TreeSet(A(2))
<console>:8: error: could not find implicit value for parameter ord: Ordering[A]
      TreeSet(A(2))

This example would work with 2.7.5 just fine.

In order to fix this one needs to define:
scala> implicit def ordered2Ordering[T <: Ordered[T]] = new Ordering[T] {
    | def compare(x: T, y: T) = x compare y
    | }
ordered2Ordering: [T <: Ordered[T]]java.lang.Object with Ordering[T]

and then:
scala> TreeSet(A(2))
res1: scala.collection.immutable.TreeSet[A] = TreeSet(A(2))

but:
scala> TreeSet(2)
<console>:7: error: type arguments [Int] do not conform to method ordered2Ordering's type parameter bounds [T <: Ordered[T]]
      TreeSet(2)
             ^

Which shows that simply adding ordered2Ordering to Predef is not a solution.

Any ideas how this should be fixed? It looks to me that Ordered vs Ordering will create a lot of confusion.

[1] http://code.google.com/p/gimd/

--
Best regards,
Grzegorz Kossakowski

Jorge Ortiz pisze:
> There's an implicit Ordering[Int] in scala.Ordering.
>

Yes but it conflicts with my function ordered2ordering.

If I don't define it then I cannot create a TreeSet consisting of Ordered elements.

Then you'll have to define your own Ordering.

--j

On Fri, Sep 18, 2009 at 10:21 AM, Grzegorz Kossakowski <grek@tuffmail.com> wrote:

Jorge Ortiz pisze:
> There's an implicit Ordering[Int] in scala.Ordering.
>

Yes but it conflicts with my function ordered2ordering.

If I don't define it then I cannot create a TreeSet consisting of Ordered elements.

--
Grzegorz Kossakowski

Jorge Ortiz wrote:
> Then you'll have to define your own Ordering.
>

Then:
a) It's rather big back-incompatibility
b) What's the point of declaring class Ordered if you cannot put to
collection that requires elements to be ordered?

On Fri, Sep 18, 2009 at 11:01:43AM -0700, Grzegorz Kossakowski wrote:
> a) It's rather big back-incompatibility
> b) What's the point of declaring class Ordered if you cannot put to
> collection that requires elements to be ordered?

I agree this is a problem, but I don't see a good way to deal with it,
and since it can be worked around it's not my highest priority at the
moment. I assume you've seen:

http://lampsvn.epfl.ch/trac/scala/ticket/2260

I'm pretty sure this means Ordered in being deprecated in favor of Ordering. Ordering is strictly more powerful because you can have several Orderings on a class Foo, whereas Foo can only ever implement Ordered once. (You can fake with by having Foo -not- implement Ordered, and making several implicit conversions to Ordered[Foo], and controlling the scope of those implicits, but this is kind of hacky and also performs very poorly.)

--j

On Fri, Sep 18, 2009 at 11:01 AM, Grzegorz Kossakowski <grek@tuffmail.com> wrote:

Jorge Ortiz wrote:

Then you'll have to define your own Ordering.

Then:
a) It's rather big back-incompatibility
b) What's the point of declaring class Ordered if you cannot put to collection that requires elements to be ordered?

Jorge Ortiz wrote:
> I'm pretty sure this means Ordered in being deprecated in favor of
> Ordering. Ordering is strictly more powerful because you can have
> several Orderings on a class Foo, whereas Foo can only ever implement
> Ordered once. (You can fake with by having Foo -not- implement
> Ordered, and making several implicit conversions to Ordered[Foo], and
> controlling the scope of those implicits, but this is kind of hacky
> and also performs very poorly.)

According to this page:
http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/...
Ordered trait is not deprecated.

I agree with you that sticking to Ordering everywhere might be a better
solution but as for now there is a big confusion in 2.8 code.

Paul Phillips wrote:
> On Fri, Sep 18, 2009 at 11:01:43AM -0700, Grzegorz Kossakowski wrote:
>
>> a) It's rather big back-incompatibility
>> b) What's the point of declaring class Ordered if you cannot put to
>> collection that requires elements to be ordered?
>>
>
> I agree this is a problem, but I don't see a good way to deal with it,
> and since it can be worked around it's not my highest priority at the
> moment. I assume you've seen:
>
> http://lampsvn.epfl.ch/trac/scala/ticket/2260
>

For some reason I missed that ticket. Thanks.

I hope this can be resolved before 2.8 is out.