Polymorphism

Petra Bierleutgeb

@pbvie

in Scala

Polymorphism

A single interface/method/function can be used with different types and...

many

forms

...choose a specific implementation based on the provided type

...work independently of the provided type, while still providing full type-safety

Different kinds

of polymorphism

Polymorphism

Ad-hoc Polymorphism

Parametric Polymorphism

Classification

Christopher Strachey
1967

Polymorphism

Ad-hoc Polymorphism

Parametric Polymorphism

Classification

polymorphic function that acts differently depending on the type of the given argument(s)

generic function or data type that works independently of the actual type - while still providing type safety

Polymorphism

Ad-hoc
Polymorphism

Parametric
Polymorphism

Classification

Peter Wegner and Luca Cardelli
1985

Inclusion Polymorphism
(subtyping)

Polymorphism

Ad-hoc
Polymorphism

Parametric
Polymorphism

Classification

Inclusion Polymorphism
(subtyping)

allows to use a subtype S of T
wherever a T is required

Essential Scala

(kindly provided by underscore)

>>> Book Tip <<<

Parametric Polymorphism

aka Generics

# Parametric Polymorphism

sometimes called Generics
- generic functions/methods
- generic data types
implementation/behavior does not depend on type
maintains type-safety

class Box[T](private val element: T) {
  def peek(): T = element
}

# Type Safety

class Box(private val element: Any) {
  def peek: Any = element
}

val i: Int = 3
val b = new Box(i)

val peeked: Any = b.peek

class Box[T](private val element: T) {
  def peek: T = element
}

val i: Int = 3
val b = new Box(i)

val peeked: Int = b.peek

with parametric polymorphism

without parametric polymorphism

# Type Safety

case class Dog(name: String, age: Int, favoriteToy: String)

val listOfDogs: List[Dog] = List(
  Dog("max", 2, "ball"),
  ...
)

listOfDogs.foreach(dog => println(s"${dog.name}'s favorite toy is ${dog.favoriteToy}"))

List[T] is a polymorphic data type

compiler knows element dog is of type Dog

# Type Safety

List[Dog]

def second[T](l: List[T]): Option[T] = l match {
  case _ :: second :: _ => Some(second)
  case _ => None
}

val secondDog: Option[Dog] = second(listOfDogs)

type param T is bound to type Dog when we pass listOfDogs to the method

def second(l: List[Dog]): Option[Dog] = ...

polymorphic function

# Conclusion

parametric polymorphism can be used to abstract over types
makes programs more expressive and improves type-safety
implementation is independent of the type parameter

Ad-hoc Polymorphism

Overloading

# Ad-hoc Polymorphism

polymorphic methods that accept arguments of different types
aka function/operator/method overloading
compiler selects implementation based on type
unlike parametric polymorphism: implementations for different types may do different things

def combine(a: Int, b: Int): Int             = a + b
def combine(a: String, b: String): String    = s"$a$b"
def combine(a: Boolean, b: Boolean): Boolean = a && b

combine(1, 3)
combine("abc", "def")
combine(true, false)
combine(List(123), List(456)) // ooops...this one won't compile

# Ad-hoc Polymorphism

overloaded methods can have a different number of parameters, in a different order, and with different types
a method is therefore uniquely identified by a combination of all these characteristics

def combine(a: Int, b: Int): Int             = a + b
def combine(a: String, b: String): String    = s"$a$b"
def combine(a: Boolean, b: Boolean): Boolean = a && b
def combine(a: Int, b: String): String       = s"${a.toString}$b"
def combine(a: String, b: Int): String       = s"$a${b.toString}"

combine(1, 3)
combine("abc", "def")
combine(true, false)
...

# Ad-hoc Polymorphism

watch out for type erasure!

// oops...doesn't compile!
def combine(l: List[Int]): String    = l.sum.toString
def combine(l: List[String]): String = l.mkString(",")

List => String

[error]       def combine(l: List[Int]): String at line 30 and
[error]       def combine(l: List[String]): String at line 32
[error]       have same type after erasure: (l: List)String

compilation error:

# Ad-hoc Polymorphism

// oops...doesn't compile!
def combine(l: List[Int]): Int       = l.sum
def combine(l: List[String]): String = l.mkString(",")

List => Int

List => String

watch out for type erasure!

works...but not recommended

# Early-Binding

overloading/dispatching is decided at compile-time

trait Animal {
  def name: String
}

final case class Dog(name: String) extends Animal
final case class Cat(name: String) extends Animal

def greeting(a: Animal): String = s"hello animal named ${a.name}"
def greeting(d: Dog): String    = s"hello dog named ${d.name}"
def greeting(c: Cat): String    = s"hello cat named ${c.name}"

# Early-Binding

What is the output of this program?

def greeting(a: Animal): String = s"hello animal named ${a.name}"
def greeting(d: Dog): String    = s"hello dog named ${d.name}"
def greeting(c: Cat): String    = s"hello cat named ${c.name}"

val d1: Dog    = Dog("max")
val d2: Animal = Dog("max")
val c1: Cat    = Cat("garfield")

println(greeting(d1))
println(greeting(d2))
println(greeting(c1))

hello dog named max
hello dog named max
hello cat named garfield

hello dog named max
hello animal named max
hello cat named garfield

# Early-Binding

What is the output of the program?

def greeting(a: Animal): String = s"hello animal named ${a.name}"
def greeting(d: Dog): String    = s"hello dog named ${d.name}"
def greeting(c: Cat): String    = s"hello cat named ${c.name}"

val d1: Dog    = Dog("max")
val d2: Animal = Dog("max")
val c1: Cat    = Cat("garfield")

println(greeting(d1))
println(greeting(d2))
println(greeting(c1))

hello dog named max
hello animal named max
hello cat named garfield

# Conclusion

method overloading
implementation selected based on type of parameters
called method is decided at compile-time (early binding)
overloading for parameterized types suffers from type erasure
in Scala: ad-hoc polymorphism often encountered in form of the Typeclass pattern

Subtyping

Inclusion Polymorphism

# Subtyping Polymorphism

relation between types that requires that we can
use some subtype T wherever its supertype S is expected
in Scala, such relationships are described by extending traits and/or classes

# Subtyping Polymorphism

trait Animal {
  def name: String
  def greeting: String = s"hello animal named $name"
}

case class Dog(name: String) extends Animal {
  override val greeting: String = s"hello dog named $name"
}

case class Cat(name: String) extends Animal {
  override val greeting: String = s"hello cat named $name"
}

subtypes must provide implementations for all abstract fields and methods defined on the supertype
fields/methods already defined on the supertype can be overriden

# Subtyping Polymorphism

def greet(toBeGreeted: Animal): Unit = println(toBeGreeted.greeting)

val d1: Dog    = Dog("max")
val d2: Animal = Dog("max")
val c1: Cat    = Cat("garfield")

greet(d1)
greet(d2)
greet(c1)

# Late Binding

def greet(toBeGreeted: Animal): Unit = println(toBeGreeted.greeting)

val d1: Dog    = Dog("max")
val d2: Animal = Dog("max")
val c1: Cat    = Cat("garfield")

greet(d1)
greet(d2)
greet(c1)

What's the output of this program?

hello dog named max
hello dog named max
hello cat named garfield

hello dog named max
hello animal named max
hello cat named garfield

# Late Binding

def greet(toBeGreeted: Animal): Unit = println(toBeGreeted.greeting)

val d1: Dog    = Dog("max")
val d2: Animal = Dog("max")
val c1: Cat    = Cat("garfield")

greet(d1)
greet(d2)
greet(c1)

What's the output of this program?

hello dog named max
hello dog named max
hello cat named garfield

# Early/Late Binding

Scala has
- early binding for method parameters
- late binding for the object on which the method is called

# Subtyping: good parts

good for modeling ADTs
- pattern using sealed traits/abstract classes and final case classes
easy to add new data without modifying existing code

# Subtyping: not-so-good parts

modify existing source code when adding new functionality
can't add traits on external code
only one implementation per type
complex/inflexible hierarchies
the (in)famous return-current-type problem

Variance and Type Bounds

Fine-tuning

# Variance

define subtyping relationships between types with type parameters

sealed trait Animal {
  def name: String
}
final case class Dog(name: String, favoriteToy: String) extends Animal
final case class Cat(name: String, favoriteFood: String) extends Animal

trait Box[T] {
 ...
}

if there's a Box[A] and B is a subtype of A, should Box[B] be a subtype of Box[A]?

# Invariance

there's no relation between Box[A] and Box[B], even if there's a sub/supertype relationship between A and B
notation: [A] (default in Scala)

trait Box[A] {
  def put(a: A): Unit
  def peek(): A
}

// can we use a Box[Dog] wherever we expect a Box[Animal]?
val dogBox: Box[Dog] = ...
val myAnimal: Animal = dogBox.peek // that's ok

val myCat: Cat = ...
def putAnimalInsideBox(animal: Animal, box: Box[Animal]) = ...

putAnimalInsideBox(myCat, dogBox) // that doesn't look good!

in general: if a type appears as produced value and consumed value it has to be invariant

# Covariance

Box[B] is a subtype of Box[A], if B is a subtype of A
notation: [+A]

class Box[+A](element: A) {
  def peek: A = element
}

def runIt(): Unit = {
  val bA: Box[Animal] = new Box(a)
  val bD: Box[Dog] = new Box(d)
  val bX: Box[Animal] = bD // works
  val myAnimal: Animal = bD.peek // it's ok to store a Dog in myAnimal
}

in general: if a type only appears as produced value (as return type), it can be made covariant

# Contravariance

Box[B] is a supertype of Box[A], if B is a subtype of A
notation: [-A]

trait Greeter[-A] {
  def greet(a: A): String
}

class AnimalGreeter extends Greeter[Animal] {
  override def greet(a: Animal): String = s"hello ${a.name}"
}

def doGreeting(greeter: Greeter[Dog]): Unit = {
  println(greeter.greet(dog))
}

val greeter = new AnimalGreeter
doGreeting(greeter)

in general: if a type only appears as consumed value (as parameter type), it can be made contravariant

limits the allowed types for a type parameter
[A <: B] A must be a subtype of B
[A >: B] A must be a supertype of B

# Type Bounds

Type Classes

The Pattern

# What is a Typeclass

first appeared in Haskell
form of ad-hoc polymorphism
- Philip Wadler and Stephen Blott:
  How to make ad-hoc polymorphism less ad hoc
allows implementing an interface for possibly unrelated types
existing code doesn't have to be modified when adding new data types or implementing functionality for new types
Typeclasses in Scala: a pattern, not a language feature

# Using Typeclasses

Scala standard lib defines some Typeclasses along with instances for common types, e.g. Ordering[T]

// simplified
trait Ordering[T] {
  def compare(x: T, y: T): Int
}

we can implement instances of a typeclass for
- our own types
- third-party types
- and have multiple/different implementations per type

# Implementing Ordering[T] for Cat

case class Cat(name: String, age: Int)

implicit val catOrdering: Ordering[Cat] = new Ordering[Cat] {
  override def compare(x: Cat, y: Cat): Int = x.age - y.age
}

val unsortedCats = List(Cat("a", 3), Cat("b", 1), Cat("c", 7))
val sortedCats   = unsortedCats.sorted(catOrdering)

// sorted takes an implicit ord: Ordering[B] so we could actually write
val alsoSortedCats = unsortedCats.sorted

# Defining Typeclasses

The full Typeclass pattern includes
- the Typeclass itself: interface (trait) with type parameter
- Typeclass instances
- interface to use the Typeclass
- enriched interfaces

:: Example ::

Describable[T]

# Describable[T]

Describable[T] provides a single method `describe` that returns an informal description of T
Goal:

// unrelated data types
case class Cat(name: String, age: Int)
case class Coffee(name: String, origin: String)

val garfield = Cat("Garfield", 3)
val coffee   = Coffee("Yirgacheffe", "Ethiopia")

println(garfield.describe)
// Cats: Furry rulers of the world. This one is named Garfield.

println(Describable[Coffee].describe(coffee))
// Coffee: Beans of Life. This one is from Ethiopia.

# The Typeclass Interface

interface/trait that takes a type parameter

trait Describable[T] {
  def describe(t: T): String
}

# Typeclass Instances

works, but not very useful yet
- explicitly select instance
- not better than writing describeCat, describeCoffee,... methods

val catDescribable: Describable[Cat] = new Describable[Cat] {
  override def describe(c: Cat): String = 
    s"Cats: Furry rulers of the world. This one is named ${c.name}"
}

val coffeeDescribable: Describable[Coffee] = new Describable[Coffee] {
  override def describe(c: Coffee): String = 
    s"Coffee: Beans of Life. This one is from ${c.origin}"
}

val cat    = Cat(...)
val coffee = Coffee(...)

catDescribable.describe(cat)
coffeeDescribable.describe(coffee)

# Interface - First attempt

trait Describable[T] {
  def describe(t: T): String
}

val catDescribable: Describable[Cat] = ...
val coffeeDescribable: Describable[Coffee] = ...

object Describer {
  def describe[T](t: T, d: Describable[T]): String = d.describe(t)
}

val cat: Cat = ...
val coffee: Coffee = ...

Describer.describe(cat, catDescribable)
Describer.describe(coffee, coffeeDescribable)

# Interface - with implicits

implicit val catDescribable: Describable[Cat] = ...
implicit val coffeeDescribable: Describable[Coffee] = ...

object Describer {
  def describe[T](t: T)(implicit d: Describable[T]): String = d.describe(t)
}

val cat: Cat = ...
val coffee: Coffee = ...

Describer.describe(cat)
Describer.describe(coffee)

we can pass an instance of any type T for which we have an implicit Describable[T] in scope

# Organizing Implicits

possible locations
- defined in current scope
- defined in companion object of T
- defined in companion object of Typeclass
- imported
local and imported implicits take precedence over implicits defined in companion objects
- possible to define defaults and override them

# ContextBounds

object Describer {
  def describe[T](t: T)(implicit d: Describable[T]): String = d.describe(t)
}

object DescriptionPrinter {
  def print[T](t: T)(implicit d: Describable[T]) = println(Describer.describe(t))
}

often, implicit params are only passed through

object DescriptionPrinter {
  def print[T: Describable](t: T) = println(Describer.describe(t))
}

context bounds can replace an implicit parameter that takes a type parameter of type T

# ContextBounds

object Describer {
  def describe[T](t: T)(implicit d: Describable[T]): String = d.describe(t)
}

implicit parameter can still be summoned using implicitly

object Describer {
  def describe[T: Describable](t: T): String = implicity[Describable[T]].describe(t)
}

# Interface - further improvements

trait Describable[T] {
  def describe(t: T): String
}

object Describer {
  def describe[T](t: T)(implicit d: Describable[T]): String = d.describe(t)
}

there's clearly some repetition here
gets worse when the typeclass has multiple methods that we want to support

# Interface

trait Describable[T] {
  def describe(t: T): String
}

object Describer {
  def apply[T](implicit d: Describable[T]): Describable[T] = d
}

usage:

// usage
Describer[Cat].describe(someCat)
Describer[Coffee].describe(someCoffee)

def printDescription[T : Describable](t: T): Unit = 
  println(Describer[T].describe(t))

we can get rid of the intermediate interface if we just want to call the methods defined on the typeclass

implicit instances need to be in scope

# Interface - Conclusion

using implicit parameters we can use a common interface for a type T if
- the interface is implemented for T (typeclass instance)
- the implementation is in implicit scope
by using implicit instances we can
- have multiple implementations for a single type
- choose an implementation by bringing the specific instance into scope

# Type Enrichment

define an interface that acts like a method defined on the type

// interface syntax
Describer[Cat].describe(someCat)
Describer[Coffee].describe(someCoffee)

// with type enrichment
someCat.describe
someCoffee.describe

# Type Enrichment

can be achieved using an implicit class

implicit class DescriberOps[T](val t: T) extends AnyVal {
  def describe(implicit d: Describable[T]): String = d.describe(t)
}

# Putting it all together

// typeclass
trait Describable[T] {
  def describe(t: T): String
}

// interface
object Describer {
  def apply[T](implicit d: Describable[T]): Describable[T] = d
}

// type enrichment
implicit class DescriberOps[T](val t: T) extends AnyVal {
  def describe(implicit d: Describable[T]): String = d.describe(t)
}

// instances
implicit val catDescribable: Describable[Cat] = ...
implicit val coffeeDescribable: Describable[Coffee] = ...

// usage
val garfield = Cat("garfield", 3)
println(garfield.describe)

# Conclusion: Good Parts

implementation of interfaces for possibly unrelated types
multiple implementations per type (selection via implicits)
implementation for external code
add new data and new functionality without modifying existing code

# Typeclasses: Not-so-good parts

Boilerplate: repetitive pattern needs to be manually implemented
- syntax improvements coming in Dotty
- Typeclass derivation (for instances)
Hard to model some scenarios
- e.g. List of objects that are Describable

Upcoming Features

Typeclasses with less boilerplate
and nicer syntax

# Describable[T] Typeclass in Scala 2

// typeclass
trait Describable[T] {
  def describe(t: T): String
}

// interface
object Describer {
  def apply[T](implicit d: Describable[T]): Describable[T] = d
}

// type enrichment
implicit class DescriberOps[T](val t: T) extends AnyVal {
  def describe(implicit d: Describable[T]): String = d.describe(t)
}

// instances
implicit val catDescribable: Describable[Cat] = ...
implicit val coffeeDescribable: Describable[Coffee] = ...

// usage
val garfield = Cat("garfield", 3)
println(garfield.describe)

# Describable[T] in Scala 3

trait Describable[T] {
  def (t: T) describe: String
}

object Describable {
  def apply[T] given Describable[T] = the[Describable[T]]
}

delegate for Describable[Cat] {
  def (c: Cat) describe: String = ...
}

val c1 = Cat("garfield", 3)
println(c1.describe)

new extension method syntax
replaces implicit classes

new keywords given and the replace implicit param and implicitly

new delegate syntax replaces definition of implicit object or val for instances

usage unchanged

Typeclass Derivation

Automatic generation of typeclass instances

Wednesday June 12th, 15:30-16:15

The Shape(less) of Type Class Derivation in Scala 3

Miles Sabin

That's it!

Thank you

>> Question Time <<