Agenda. CS301 Session 11. Common type constructors. Things we could add to Impcore. Discussion: midterm exam - take-home or inclass?

Transcription

1 Agenda CS301 Session 11 Discussion: midterm exam - take-home or inclass? Interlude: common type constructors Type soundness 1 2 Things we could add to Impcore Common type constructors Array is a type constructor, not a single type We're familiar with other type constructors from the garden-variety programming languages we use all the time...but now is a good time to analyze them in a language-independent way Our typing rules will assume just one type environment Γ 3 4

2 Three common type constructors (First-class) functions Products Sums Type constructor First-class functions Infix, two arguments: Formation rule: τ 1 τ 2 τ 1 and τ 2 are types τ 1 τ 2 is a type 5 6 Typing rules for functions Introduction Γ{x τ} e : τ Γ lambda(x : τ, e) : τ τ Elimination Γ e 1 : τ τ Γ e 2 : τ Γ apply(e 1, e 2 ) : τ Products (pairs) Constituent types need not be the same Variously, "tuple", "struct", "record" Can be used to model objects (in the OO sense) Formation τ 1 and τ 2 are types τ 1 τ 2 is a type 7 8

3 Typing rules for products Introduction Γ e 1 : τ 1 Γ e 2 : τ 2 Γ pair(e 1, e 2 ) : τ 1 τ 2 An elegant elim rule Like a pattern match Γ e : τ 1 τ 2 Γ{x 1 τ 1, x 2 τ 2 } e : τ Elimination Γ e : τ 1 τ 2 Γ fst(e) : τ 1 Γ letpair(x 1, x 2, e, e ) : τ (and similarly for the second element) 9 10 Generalizing pairs In ML and related languages pairs are generalized to records with named fields Your homework contains a similar problem about sum types Formation: τ 1... τ n are types {name 1 : τ 1,..., name n : τ n } is a type Introduction Elimination Typing records {name 1 : τ 1,..., name n : τ n } is a type Γ e 1 : τ 1,..., Γ e n : τ n Γ record(name 1 = e 1,..., name n = e n ) : {name 1 : τ 1,..., name n : τ n } Γ e : {name 1 : τ 1,..., name n : τ n } name = name i, 1 i n Γ getfield(name, e) : τ i 11 12

4 More elegant elim rule Again like a pattern match Γ e : {name 1 : τ 1,..., name n : τ n } Γ{x 1 τ 1,..., x n τ n e : τ Γ letrecord(x 1,..., x n, e, e ) : τ A type that unions other types together Sum types Like C unions, but safer because you can always tell what's there Like simple ML datatypes (no recursion) Formation rule τ 1 and τ 2 are types τ 1 + τ 2 is a type Typing rules for unions Introduction Γ e : τ 1 τ 2 is a type Γ left τ2 (e) : τ 1 + τ 2 Typing rules for unions(2) Elimination: like case or switch Γ e : τ 1 + τ 2 Γ{x 1 τ 1 } e 1 : τ Γ{x 2 τ 2 } e 2 : τ Γ e : τ 2 τ 1 is a type Γ case e of left(x 1 ) e 1 right(x 2 ) e 2 : τ Γ right τ1 (e) : τ 1 + τ

5 About type soundness Why trust a type system? Given a complex enough type system, we might be unable to see whether it behaves reasonably Language designers prove type soundness both to increase trust and to be explicit about what guarantees the type system provides What is type soundness? A kind of claim we make about the relationship between the typing rules and the evaluation rules Loosely, "well-typed programs don't go wrong" Sample corollaries: Functions always receive the right number and kind of arguments No array access is out of bounds (a more advanced kind of type system) Machinery needed for soundness The meaning of a type τ is a set of values Examples int = {number(n) n is an integer} bool = {bool(#t), bool(#f)} This gives us a notation for the set of things a well typed expression is allowed to evaluate to 19 20

6 Proper environments If Γ and ρ are typing and value environments, respectively, we say ρ agrees with Γ whenever, for every x in dom (Γ), 1. x is also in dom (ρ), and 2. ρ(x) Γ(x) If A soundness claim 1. Γ and ρ are typing and value environments, and 2. ρ agrees with Γ, and 3. Γ e : τ and ρ, e v, then v τ 21 22

7 Agenda CS301 Session 12 Side trip: the semantics of defining and applying recursive functions Introduction to polymorphic type systems A polymorphic type system for uscheme 1 2 Recursive functions 4

8 How can recursion work? Rule: all names are evaluated by looking them up in an environment How do we arrange for the name f to be meaningful in: (define f (n e) (if (= e 0) 1 (* n (f n (- e 1))))) Simple case: Impcore Functions are not first-class; special function environment We just bind the function name to a piece of abstract syntax x 1,...,x n all distinct D DEFINE( f, x 1,...,x n,e),ξ,φ ξ,φ{ f USER( x 1,...,x n,e)} 5 6 Impcore function application By the time we use a recursive function, its definition is already in the function environment φ( f ) = USER( x 1,...,x n,e) x 1,...,x n all distinct e 1,ξ 0,φ,ρ 0 v 1,ξ 1,φ,ρ 1. e n,ξ n 1,φ,ρ n 1 v n,ξ n,φ,ρ n e,ξ n,φ,{x 1 v 1,...x n v n } v,ξ,φ,ρ n APPLY( f,e 1,e 2,...,e n ),ξ 0,φ,ρ 0 v,ξ,φ,ρ n First-class functions What about uscheme? How do we make sure the name of the recursive function is properly bound in the body? 7 8

9 Lambdas evaluate to closures Functions Function applications l 1,..., l n dom σ Functions x 1,..., x n all distinct lambda( x 1,..., x n, e), ρ, σ lambda( x 1,..., x n, e), ρ, σ e, ρ, σ lambda( x 1,..., x n, e c ), ρ c, σ 0 e 1, ρ, σ 0 v 1, σ 1. e n, ρ, σ n 1 v n, σ n e c, ρ c {x 1 l 1,..., x n l n }, σ n {l 1 v 1,..., l n v n } v, σ apply(e, e 1,..., e n ), ρ, σ v, σ 9 10 Local recursive definition When a recursive function is applied, how/where is its name bound? Top-level recursive definitions Left as an exercise...do it! l 1,..., l n dom σ ρ = ρ{x 1 l 1,..., x n l n } σ 0 = σ{l 1 unspecified,..., l n unspecified} e 1, ρ, σ 0 v 1, σ 1. e n, ρ, σ n 1 v n, σ n e, ρ, σ n {l 1 v 1,..., l n v n } v, σ letrec( x 1, e 1,..., x n, e n, e), ρ, σ v, σ 11 12

10 Perspective Polymorphic type systems Flexibility of dynamic typing (Scheme) both a blessing and a curse Great for small systems, prototypes, and god-like programmers Not so great for large systems, production code, trusted code, teams of ordinary mortals Limitations of monomorphic typing Example from typed Impcore: list processing functions Where we're going Introduce polymorphic type system with static type checking Now we can write one version of length with type α. α list int (forall ('a) (function ((list 'a)) int)) This will be flexible enough to type a lot of the programs we want - almost a "sweet spot"...but terribly verbose and impossible to use 15 16

11 20 Why torture ourselves with this type system? Why? To motivate type inference as in ML and related languages The real "sweet spot": polymorphic type system, plus type inference, yields a terse, flexible language with robust guarantees suitable for production programming Used in ML, OCaml, Haskell, etc. etc. Type variables A new kind of variable that stands for an unknown type Actual types are supplied by type instantiation, a.k.a. type application Type variables are bound in types by (abstractly), or forall (concretely) Bound in expressions by tylambda (abstractly), or type-lambda (concretely) Idea: lambda for types You've seen this before: Java/C++ generics Quantified types: α 1,..., α n. τ (forall ('a1... 'an) type) Type abstraction: tylambda(α 1,..., α n, e) (type-lambda ('a1... 'an) exp) Type application: tyapply(e, τ 1,..., τ n ) (@ exp type1... typen) Quantified types -> length <procedure> : (forall ('a) (function ((list 'a)) int)) -> cons <procedure> : (forall ('a) (function ('a (list 'a)) (list 'a))) -> car <procedure> : (forall ('a) (function ((list 'a)) 'a)) -> cdr <procedure> : (forall ('a) (function ((list 'a)) (list 'a))) -> '() () : (forall ('a) (list 'a)) 19

12 Type instantiation -> (val length-int length int)) length-int : (function ((list int)) int) -> (val length-bool (@ length bool)) length-bool : (function ((list bool)) int) -> (val nil-bool (@ '() bool)) () : (list bool) Type abstraction -> (val-rec (forall ('a) (function ((list 'a)) int)) len (type-lambda ('a) (lambda (((list 'a) l)) (if ((@ null? 'a) l) 0 (+ 1 ((@ len 'a) ((@ cdr 'a) l))))))) len : (forall ('a) (function ((list 'a)) int)) -> (@ len int) <procedure> : (function ((list int)) int) -> ((@ len int) '(1 2 3)) 3 : int Instantiation substitutes actual types for type variables 21 22