Principal type-schemes
for functional programs
Luis Damas and Robin Milner (POPL `82)
Slide 2
Slide 2 text
Agenda
● Slides
● Code
Slide 3
Slide 3 text
ML
● Meta Language for LCF
● Type inference
● Influence on Haskell, Rust, F#, OCaml, ...
● “Sweet spot” in type system design
Slide 4
Slide 4 text
ML
letrec f xs = if null xs then nil
else snoc (f (tl xs)) (hd xs)
What type does this function have?
null : ∀ ( list → bool)
snoc : ∀ ( list → → list)
hd, tl : ∀ ( list → )
nil : ∀ ( list)
Slide 5
Slide 5 text
ML
What about:
let s x y z = x z (y z)
?
Slide 6
Slide 6 text
Type Inference
f : ∀ ( list → list)
● Given f, how can we infer this type?
● What does it even mean for a value to have a type?
● How can we be sure we have the most general type?
Slide 7
Slide 7 text
Lambda Calculus
Expressions e:
● Identifiers: , , …
● Applications: e e’
● Abstractions: . e
● Let bindings: let = e in e’
Type Schemes
Type schemes :
● Monomorphic:
● Polymorphic: ∀ .
Type schemes are types with identifiers bound by ∀ at the
front.
Slide 11
Slide 11 text
Substitutions
Mappings from variables to types
● Can instantiate type schemes using substitutions
● Gives a simple subtyping relation on type schemes
Slide 12
Slide 12 text
Semantics
Construct a semantic domain (CPO) V containing
● Primitives
● Functions
● An error element
and a semantic function : e → (Id → V) → V
Slide 13
Slide 13 text
Semantics
Identify types with subsets of V
Define the judgment
A ╞ e :
when (∀ ( : ’) ∈ A. ∈ ’) ⇒ e ∈
Slide 14
Slide 14 text
Declarative System
Variable rule:
Slide 15
Slide 15 text
Declarative System
Application rule:
Slide 16
Slide 16 text
Declarative System
Abstraction rule:
Slide 17
Slide 17 text
Declarative System
Let rule:
Slide 18
Slide 18 text
Declarative System
Instantiation rule:
Slide 19
Slide 19 text
Declarative System
Generalization rule:
Slide 20
Slide 20 text
Soundness
If
A e :
then
A ╞ e :
“Static behavior determines dynamic behavior”
Slide 21
Slide 21 text
Example
Prove:
. : ∀ . ( → → ) → →
Slide 22
Slide 22 text
Algorithm W
● The inference rules do not translate easily into an
algorithm (why not?)
● Introduce
w : Exp → Env → (Env, )
Slide 23
Slide 23 text
Algorithm W
● W attempts to build a substitution, bottom-up
● W can fail with an error if there is no valid typing
● Intuition:
○ Collect constraints
○ Then solve constraints
● Reality: W is the fusion of these two steps
● See the code!
Slide 24
Slide 24 text
Unification
● Unification gives local information about types
● We assemble a global solution from local information
Occurs Check
Prevents inference of infinite types
w( . , nil) = error!
Can’t unify ~ if occurs in the body of .
E.g. ~ →
~ ((… → ) → ) →
Slide 27
Slide 27 text
Soundness
If
w(A, e) = (S, )
then
A e :
“Algorithm W constructs typing judgments”
Slide 28
Slide 28 text
Completeness
If
A e :
then w(A, e) constructs a typing judgment for e which
generalises the above.
“Algorithm W constructs principal types”
Slide 29
Slide 29 text
Further Reading
More type systems
● System F, F⍵
● Rank-N types
● Type Classes
● Dependent Types
● Refinement Types
Other approaches
● Constraints
● Bidirectional typechecking
● SMT
See TAPL & ATAPL!
Slide 30
Slide 30 text
Acknowledgments
DHM axioms reproduced from Wikipedia under
the CC-3.0 Attribution/ShareAlike license