cs-4400-sp26

Lecture 8: Simply-Typed Lambda Calculus

Lecture outline

• IfLang type soundness proof
• Scope checking (adding Let)
• STLC: a type system for lambda calculus
• Implementing STLC

Review: IfLang type system

Typing rules: Judgment form: e : t

--------- ty/tt      ----------- ty/ff    ------------------ ty/n
tt : Bool             ff : Bool            (num n) : Number

e1 : Number     e2 : Number
--------------------------- ty/+
   (e1 + e2) : Number
   
e : Bool     e1 : t     e2 : t
------------------------------- ty/if
   if e then e1 else e2 : t

Concept: these rules are syntax-directed. That is, there is exactly one rule matching every syntactic form in the language.

IfLang Soundness

“Well-typed programs don’t go wrong” => “Well-typed programs evaluate to a value of the same type” => If e : t, then e ==> v and v : t

Proof: by induction over the derivation of e : t

Look at each inference rule for e ==> v one by one:

• (num n) : Num, tt : Bool, and ff : Bool all work trivially
• e1 + e2 : Num when e1 : Num and e2 : Num:
  • Assume for IH that e1 ==> v1, e2 ==> v2, v1 : Num and v2 : Num
  • Because numbers are the only values of type Num, v1 must be num n and v2 must be num m for some numbers n and m
  • Thus by rule eval/plus, (e1 + e2) ==> num (n + m), and num (n + m) is a value of type Num
• if e then e1 else e2 when e : Bool and there exists a type t such that e1 : t and e2 : t:
  • Assume for IH:
    • e ==> v and v : Bool.
    • e1 ==> v1 and v1 : t.
    • e2 ==> v2 and v2 : t.
    • The only possibilities for v are tt and ff.
      • Case 1: v = tt. Then by rule eval/if, it suffices to show a v for which e1 ==> v and v : t. Let v be v1 and then we have what we need from IH.
      • Case 2: v = ff. Similar to previous case but for e2 and v2.

Scope Checking

Jugment: Γ ⊢ e ok – means e is well-scoped, i.e. all of its free variables are in Γ.

Examples:

• GOOD: y ⊢ (let x = 10 in x + y)
• BAD: ⋅ ⊢ (let x = 10 in x + y)

Goal property:

• If ⋅ ⊢ e ok then running e will not result in any unbound variable errors.

x ∈ Γ
--------- ok/var
Γ ⊢ x ok


---------------- ok/num
Γ ⊢ (num n) ok


Γ ⊢ e1 ok    Γ, x ⊢ e2 ok
----------------------------- ok/let
Γ ⊢ (let x = e1 in e2) ok

Exercise: check the good/bad example above.

STLC

Type errors we want to rule out:

• Applying non-functions, e.g. (10 3)
• Adding non-numbers, e.g. (λx.x) + 3
• Applying function to argument of wrong type, e.g. (λx. x + x) (λy.y)

Inference rules*

Values: v ::= num n | λx.e

Types: t ::= Num | t -> t

Expressions: e ::= num n | e + e | λx.e | e e | x

x : t ∈ Γ
------------ ty/var
Γ ⊢ x : t

------------------ ty/num
Γ ⊢ (num n) : Num


Γ ⊢ e1 : Num    Γ ⊢ e2 : Num
------------------------------- ty/+
Γ ⊢ e1 + e2  :  Num


Γ, x : t ⊢ e : s
--------------------- ty/λ
Γ ⊢ λx.e  :  t -> s


Γ ⊢ e1 : t -> s     Γ ⊢ e2 : t1
--------------------------------- ty/app
Γ ⊢ (e1 e2) : s

Exercises

• Give a typing derivation for (λx.x) : Num -> Num
  • What other types could go after the : and still have a derivation?
• Give a typing derivation for ((λx.x) (num 10)) : Num
• Give a typing derivation for (λx.x) (λy.y) : Num -> Num
• Give a typing derivation for (λf.f (num 10)) : (Num -> Num) -> Num
• Attempt to give a type derivation for the “bad” examples above, and see why they fail
• Attempt to give a type derivation for self-application (λx.x) (λx.x)

  Properties

• Completeness: not actually true! Self-application is a counterexample.
• Soundness: true, but much more difficult to establish!

If we write a small step semantics, we can prove something easier:

If e : t, then either e is a value of type t, or e can take a step to some e' : t.

This formulation is sometimes broken out into two lemmas, known as progress and preservation:

• Progress: If e : t then either e is a value or can take a step.
• Preservation: If e : t and e steps to e', then e' : t.

Some lemmas, representative of key ideas in designing type systems:

• Canonical forms: If e : t and e is a value, then e is one of the canonical values of type t. For example, if t is an arrow (function) type, then e must be a function.
• Substitution: Substitution preserves typing. That is, if G, x: t |- e : s and esub : t, then G |- [esub/x]e : s.
• Determinacy: evaluation is deterministic. That is, if e => v and e => v' with v and v' values, v = v'.
• Finality of values: If . |- e : t and e is a value, it can’t take a step.

Implementing STLC

Take a look at the rules and think about how to implement them.

Can we write a type checker?

• The app rule makes this tricky.

Can we write a type synthesizer?

• The lam rule makes this tricky.

There are a lot of approaches to resolving this, but one way is to ask the programmer to provide type annotations in certain places.

In particular, if we ask λ expressions to annotate their input type, we can write a type synthesizer.

See lec8-stlc.rkt for code.

Further reading

Frank Pfenning on Simple Types