Orderings and TreeMap - scala

Question

I'm building a MultiSet[A] and using a TreeMap[A, Int] to keep track of the elements.
class MultiSet[A <: Ordered[A] ](val tm: TreeMap[A, Int]) { ... }
Now I want to create a MultiSet[Int] using this framework. In particular, I want a method that will take a Vector[Int] and produce a TreeMap[Int, Int] that I can use to make a MultiSet[Int].
I wrote the following vectorToTreeMap, which compiles without complaint.
def vectorToTreeMap[A <: Ordered[A]](elements: Vector[A]): TreeMap[A, Int] =
elements.foldLeft(new TreeMap[A, Int]())((tm, e) => tm.updated(e, tm.getOrElse(e, 0) + 1))
But when I try
val tm: TreeMap[Int, Int] = vectorToTreeMap(Vector(1, 2, 3))
I get compiler complaints saying that Int doesn't conform to A <: Ordered[A]. What does it take to create a TreeMap[Int, Int] in this context? (I want the more general case because the MultiSet[A] is not always MultiSet[Int].)
I also tried A <: scala.math.Ordered[A] and A <: Ordering[A] but with no better results. (I'll admit that I don't understand the differences among the three possibilities and whether it matters in this situation.)
Thanks for your help.

Answer 1

The problem is that Int is an alias for the java int, which does not implement Ordered[Int]. How could it, since java does not even know that the Ordered[T] trait exists.
There are two ways to solve your problem:
View bounds:
The first approach is to change the constraint <: to a view bound <%.
def vectorToTreeMap[A <% Ordered[A]](elements: Vector[A]): TreeMap[A, Int] =
elements.foldLeft(new TreeMap[A, Int]())((tm, e) => tm.updated(e, tm.getOrElse(e, 0) + 1))
A <: Ordered[A] means that the method vectorToTreeMap is only defined for types that directly implement Ordered[A], which excludes Int.
A <% Ordered[A] means that the method vectorToTreeMap is defined for all types that "can be viewed as" implementing Ordered[A], which includes Int because there is an implicit conversion defined from Int to Ordered[Int]:
scala> implicitly[Int => Ordered[Int]]
res7: Int => Ordered[Int] = <function1>
Type classes
The second approach is to not require any (direct or indirect) inheritance relationship for the type A, but just require that there exists a way to order instances of type A.
Basically you always require an ordering to be able to create a TreeMap from a vector, but to avoid having to pass it every single time you call the method you make the ordering an implicit parameter.
def vectorToTreeMap[A](elements: Vector[A])(implicit ordering:Ordering[A]): TreeMap[A, Int] =
elements.foldLeft(new TreeMap[A, Int]())((tm, e) => tm.updated(e, tm.getOrElse(e, 0) + 1))
It turns out that there are instances of Ordering[A] for all java primitive types as well as for String, as you can see with the implicitly method in the scala REPL:
scala> implicitly[Ordering[Int]]
res8: Ordering[Int] = scala.math.Ordering$Int$#5b748182
Scala is even able to derive orderings for composite types. For example if you have a Tuple where there exists an ordering for each element type, scala will automatically provide an ordering for the tuple type as well:
scala> implicitly[Ordering[(Int, Int)]]
res9: Ordering[(Int, Int)] = scala.math.Ordering$$anon$11#66d51003
The second approach of using so-called type classes is much more flexible. For example, if you want a tree of plain old ints, but with reverse order, all you have to do is to provide a reverse int ordering either directly or as an implicit val.
This approach is also very common in idiomatic scala. So there is even special syntax for it:
def vectorToTreeMap[A : Ordering](elements: Vector[A]): TreeMap[A, Int] = ???
is equivalent to
def vectorToTreeMap[A](elements: Vector[A])(implicit ordering:Ordering[A]): TreeMap[A, Int] = ???
It basically means that you want the method vectorToTreeMap defined only for types for which an ordering exists, but you do not care about giving the ordering a name. Even with the short syntax you can use vectorToTreeMap with an implicitly resolved Ordering[A], or pass an Ordering[A] explicitly.
The second approach has two big advantages:
it allows you to define functionality for types you do not "own".
it allows you to decouple the behavior regarding some aspect like e.g. ordering from the type itself, whereas with the inheritance approach you couple the behavior to the type. For example you can have a normal Ordering and a caseInsensitiveOrdering for a Sting. But if you let String extend from Ordered, you must decide on one ordering behavior.
That is why the second approach is used in the scala collections itself to provide an ordering for TreeMap.
Edit: here is an example to provide an ordering for a type that does not have one:
scala> case class Person(name:String, surname:String)
defined class Person
scala> implicitly[Ordering[Person]]
<console>:10: error: No implicit Ordering defined for Person.
implicitly[Ordering[Person]]
^
Case classes do not have orderings automatically defined. But we can easily define one:
scala> :paste
// Entering paste mode (ctrl-D to finish)
case class Person(name:String, surname:String)
object Person {
// just convert to a tuple, which is ordered by the individual elements
val nameSurnameOrdering : Ordering[Person] = Ordering.by(p => (p.name, p.surname))
// make the nameSurnameOrdering the default that is in scope unless something else is specified
implicit def defaultOrdering = nameSurnameOrdering
}
// Exiting paste mode, now interpreting.
defined class Person
defined module Person
scala> implicitly[Ordering[Person]]
res1: Ordering[Person] = scala.math.Ordering$$anon$9#50148190