# A Spectrum of Types

Luca Franceschini

PhD seminars series @ DIBRIS
23 May 2019

(stolen title)

## Static

• Static guarantees
• More verbose
• Stricter
• More scalable
• "I'm used to it"

## Dynamic

• Dynamic checks
• Less typing (pun intended)
• More freedom
• Better prototyping
• "Everyone uses it"

## CONCISENESS

fun doCoolStuff(a, b) {
// bla bla
var x = a.method();
var y = b.anotherMetod();
return a+b;
}
fun doCoolStuff(a: String, b: Int): Int {
// bla bla with types
var x: Int = a.method();
var y: Int = b.anotherMetod();
return x+y;
}

## CONCISENESS?

fun doCoolStuff(a, b) {
if (a !is String)
throw Exception("gimme a string")
if (a !is Int)
throw Exception("gimme a number")

// bla bla
var x = a.method();
var y = b.anotherMetod();
return a+b;
}
fun doCoolStuff(a: String, b: Int): Int {
// bla bla with types
var x: Int = a.method();
var y: Int = b.anotherMetod();
return x+y;
}

## CONCISENESS...

/**
* {a} must be of type String.
* {b} must be of type Int.
* {return}s an object of type Int.
*/
fun doCoolStuff(a, b) {
if (a !is String)
throw Exception("gimme a string")
if (a !is Int)
throw Exception("gimme a number")

// bla bla
var x = a.method();
var y = b.anotherMetod();
return a+b;
}
fun doCoolStuff(a: String, b: Int): Int {
// bla bla with types
var x: Int = a.method();
var y: Int = b.anotherMetod();
return x+y;
}

... and maybe some not-that-interesting unit tests

## DUCK TYPING

fun doCoolStuff(a, b) {
// bla bla
var x = a.method();
var y = b.anotherMetod();
return a+b;
}
fun doCoolStuff(a: String, b: Int): Int {
// bla bla with types
var x: Int = a.method();
var y: Int = b.anotherMetod();
return x+y;
}

The Python way: "If it walks like a duck and it quacks like a duck, then it must be a duck"

bartender.shot()
gun.shot()

## A SUBTLE BUG

// some stuff

writer.write(myInt);

// some more

## A SUBTLE BUG

// some stuff

writer.write(7);

// some more

## A SUBTLE BUG

### Many programmers have used dynamically typed languages very poorly."

["What to Know Before Debating Type Systems", Chris Smith, 2011]

"You take the blue pill, the story ends, you wake up in your Python IDE and write whatever you want to write. You take the red pill, you stay in Type theory, and I show you how deep the rabbit hole goes." (~Matrix)

# How far can we go with types?

fun doCoolStuff(a: String, b: Int): Int {
// bla bla with types
var x: Int = a.method();
var y: Int = b.anotherMetod();
return x+y;
}
\mathit{doCoolStuff} \;:\; \mathit{String} \to \mathit{Int} \to \mathit{Int}

## SIMPLE TYPES

fun <T> length(l: List<T>): Int {
// somehow count elements...
return size;
}
\mathit{length} \;:\; \forall T . [T] \to \mathit{Int}
• Variance
• Wildcards
• Constraints
• F-bounded quantification
fun foo(l: List<Apple>) { ... }

// should this work?
foo(listOf<GreenApple>());

// should this work?
foo(listOf<Fruit>());
// Java

void foo(List<? extends Apple> l) { ... }

// this now works
foo(listOf<GreenApple>());

// this doesn't
foo(listOf<Fruit>());
// C#

void foo<T>(T obj) where T : new() {
// here I can do this
var x = new T();
}
// Java

void <T> sort(
List<T extends Comparable<T>> l) {
// sorting algorithm
}

## POLYMORPHIC TYPES

data Tree a = Leaf
| Node a (Tree a) (Tree a)
\mathit{stringTree} \;:\; \mathit{Tree}\; \mathit{String}

"son"

\mathit{Tree} \;:\; * \to *
\mathit{String} \;:\; *
let stringTree = Node "dad"
Leaf
(Node "son" Leaf Leaf)

## DEPENDENT TYPES

data Vec : Nat -> Type -> Type where ...
u = ["foo"]
v = [1, 2, 3]
u \;:\; \mathit{Vec}\ 1\ \mathit{String}
\mathit{concat} \;:\; \mathit{Vec}\ T\ n \to \mathit{Vec}\ T\ m \to \mathit{Vec}\ T\ (m+n)
v \;:\; \mathit{Vec}\ 3\ \mathit{Int}

## (a lot of) THINGS I IGNORED

• Types outside the cube
• Set-theoretic types
• Behavioral types