Programming Languages and Compilers (CS 421) Elsa L Gunter 2112 SC, UIUC http://courses.engr.illinois.edu/cs421 Based in part on slides by Mattox Beckman, as updated by Vikram Adve and Gul Agha 5/11/2018

Nested Recursive Types # type 'a labeled_tree = TreeNode of ('a * 'a labeled_tree list);; type 'a labeled_tree = TreeNode of ('a * 'a labeled_tree list) 5/11/2018

Nested Recursive Type Values # let ltree = TreeNode(5, [TreeNode (3, []); TreeNode (2, [TreeNode (1, []); TreeNode (7, [])]); TreeNode (5, [])]);; 5/11/2018

Nested Recursive Type Values val ltree : int labeled_tree = TreeNode (5, [TreeNode (3, []); TreeNode (2, [TreeNode (1, []); TreeNode (7, [])]); TreeNode (5, [])]) 5/11/2018

Nested Recursive Type Values Ltree = TreeNode(5) :: :: :: [ ] TreeNode(3) TreeNode(2) TreeNode(5) [ ] :: :: [ ] [ ] TreeNode(1) TreeNode(7) [ ] [ ] 5/11/2018

Nested Recursive Type Values 5 3 2 5 1 7 5/11/2018

Mutually Recursive Functions # let rec flatten_tree labtree = match labtree with TreeNode (x,treelist) -> x::flatten_tree_list treelist and flatten_tree_list treelist = match treelist with [] -> [] | labtree::labtrees -> flatten_tree labtree @ flatten_tree_list labtrees;; 5/11/2018

Mutually Recursive Functions val flatten_tree : 'a labeled_tree -> 'a list = <fun> val flatten_tree_list : 'a labeled_tree list -> 'a list = <fun> # flatten_tree ltree;; - : int list = [5; 3; 2; 1; 7; 5] Nested recursive types lead to mutually recursive functions 5/11/2018

Data types play a key role in: Why Data Types? Data types play a key role in: Data abstraction in the design of programs Type checking in the analysis of programs Compile-time code generation in the translation and execution of programs Data layout (how many words; which are data and which are pointers) dictated by type 5/11/2018

Type: A type t defines a set of possible data values Terminology Type: A type t defines a set of possible data values E.g. short in C is {x| 215 - 1  x  -215} A value in this set is said to have type t Type system: rules of a language assigning types to expressions 5/11/2018

Types as Specifications Types describe properties Different type systems describe different properties, eg Data is read-write versus read-only Operation has authority to access data Data came from “right” source Operation might or could not raise an exception Common type systems focus on types describing same data layout and access methods 5/11/2018

Sound Type System If an expression is assigned type t, and it evaluates to a value v, then v is in the set of values defined by t SML, OCAML, Scheme and Ada have sound type systems Most implementations of C and C++ do not 5/11/2018

Strongly Typed Language When no application of an operator to arguments can lead to a run-time type error, language is strongly typed Eg: 1 + 2.3;; Depends on definition of “type error” 5/11/2018

Strongly Typed Language C++ claimed to be “strongly typed”, but Union types allow creating a value at one type and using it at another Type coercions may cause unexpected (undesirable) effects No array bounds check (in fact, no runtime checks at all) SML, OCAML “strongly typed” but still must do dynamic array bounds checks, runtime type case analysis, and other checks 5/11/2018

Static vs Dynamic Types Static type: type assigned to an expression at compile time Dynamic type: type assigned to a storage location at run time Statically typed language: static type assigned to every expression at compile time Dynamically typed language: type of an expression determined at run time 5/11/2018

Type Checking When is op(arg1,…,argn) allowed? Type checking assures that operations are applied to the right number of arguments of the right types Right type may mean same type as was specified, or may mean that there is a predefined implicit coercion that will be applied Used to resolve overloaded operations 5/11/2018

Statically typed languages can do most type checking statically Type checking may be done statically at compile time or dynamically at run time Dynamically typed (aka untyped) languages (eg LISP, Prolog) do only dynamic type checking Statically typed languages can do most type checking statically 5/11/2018

Performed at run-time before each operation is applied Dynamic Type Checking Performed at run-time before each operation is applied Types of variables and operations left unspecified until run-time Same variable may be used at different types 5/11/2018

Data object must contain type information Dynamic Type Checking Data object must contain type information Errors aren’t detected until violating application is executed (maybe years after the code was written) 5/11/2018

Performed after parsing, before code generation Static Type Checking Performed after parsing, before code generation Type of every variable and signature of every operator must be known at compile time 5/11/2018

Catches many programming errors at earliest point Static Type Checking Can eliminate need to store type information in data object if no dynamic type checking is needed Catches many programming errors at earliest point Can’t check types that depend on dynamically computed values Eg: array bounds 5/11/2018

Static Type Checking Typically places restrictions on languages Garbage collection References instead of pointers All variables initialized when created Variable only used at one type Union types allow for work-arounds, but effectively introduce dynamic type checks 5/11/2018

Type Declarations Type declarations: explicit assignment of types to variables (signatures to functions) in the code of a program Must be checked in a strongly typed language Often not necessary for strong typing or even static typing (depends on the type system) 5/11/2018

Type Inference Type inference: A program analysis to assign a type to an expression from the program context of the expression Fully static type inference first introduced by Robin Miller in ML Haskle, OCAML, SML all use type inference Records are a problem for type inference 5/11/2018

Format of Type Judgments A type judgement has the form  |- exp :   is a typing environment Supplies the types of variables (and function names when function names are not variables)  is a set of the form { x : , . . . } For any x at most one  such that (x :   ) exp is a program expression  is a type to be assigned to exp |- pronounced “turnstyle”, or “entails” (or “satisfies” or, informally, “shows”) 5/11/2018

Axioms - Constants  |- n : int (assuming n is an integer constant)  |- true : bool  |- false : bool These rules are true with any typing environment , n are meta-variables 5/11/2018

Axioms – Variables (Monomorphic Rule) Notation: Let (x) =  if x :    Note: if such  exits, its unique Variable axiom:  |- x :  if (x) =  5/11/2018

Simple Rules - Arithmetic Primitive operators (   { +, -, *, …}):  |- e1:1  |- e2:2 ():1  2  3  |- e1  e2 : 3 Relations ( ˜  { < , > , =, <=, >= }):  |- e1 :   |- e2 :   |- e1 ˜ e2 :bool For the moment, think  is int 5/11/2018

Example: {x:int} |- x + 2 = 3 :bool What do we need to show first? {x:int} |- x:int {x:int} |- 2:int {x : int} |- x + 2 : bool {x:int} |- 3 :int {x:int} |- x + 2 = 3 : bool 5/11/2018

Example: {x:int} |- x + 2 = 3 :bool What do we need for the left side? {x:int} |- x:int {x:int} |- 2:int {x : int} |- x + 2 : int {x:int} |- 3 :int {x:int} |- x + 2 = 3 : bool Rel 5/11/2018

Example: {x:int} |- x + 2 = 3 :bool How to finish? {x:int} |- x:int {x:int} |- 2:int {x : int} |- x + 2 : int {x:int} |- 3 :int {x:int} |- x + 2 = 3 : bool AO Rel 5/11/2018

Example: {x:int} |- x + 2 = 3 :bool Complete Proof (type derivation) {x:int} |- x:int {x:int} |- 2:int {x : int} |- x + 2 : int {x:int} |- 3 :int {x:int} |- x + 2 = 3 : bool Var Const Const AO Rel 5/11/2018

Simple Rules - Booleans Connectives  |- e1 : bool  |- e2 : bool  |- e1 && e2 : bool  |- e1 || e2 : bool 5/11/2018

Type Variables in Rules If_then_else rule:  |- e1 : bool  |- e2 :   |- e3 :   |- (if e1 then e2 else e3) :   is a type variable (meta-variable) Can take any type at all All instances in a rule application must get same type Then branch, else branch and if_then_else must all have same type 5/11/2018

Function Application Application rule:  |- e1 : 1  2  |- e2 : 1 If you have a function expression e1 of type 1  2 applied to an argument e2 of type 1, the resulting expression e1e2 has type 2 5/11/2018

Rules describe types, but also how the environment  may change Fun Rule Rules describe types, but also how the environment  may change Can only do what rule allows! fun rule: {x : 1 } +  |- e : 2  |- fun x -> e : 1  2 5/11/2018

Fun Examples {y : int } +  |- y + 3 : int  |- fun y -> y + 3 : int  int {f : int  bool} +  |- f 2 :: [true] : bool list  |- (fun f -> f 2 :: [true]) : (int  bool)  bool list 5/11/2018

(Monomorphic) Let and Let Rec let rule:  |- e1 : 1 {x : 1} +  |- e2 : 2  |- (let x = e1 in e2 ) : 2 let rec rule: {x: 1} +  |- e1:1 {x: 1} +  |- e2:2  |- (let rec x = e1 in e2 ) : 2 5/11/2018

Example Which rule do we apply? ? |- (let rec one = 1 :: one in let x = 2 in fun y -> (x :: y :: one) ) : int  int list 5/11/2018

Example Let rec rule: 2 {one : int list} |- 1 (let x = 2 in {one : int list} |- fun y -> (x :: y :: one)) (1 :: one) : int list : int  int list |- (let rec one = 1 :: one in let x = 2 in fun y -> (x :: y :: one) ) : int  int list 5/11/2018

{one : int list} |- (1 :: one) : int list Proof of 1 Which rule? {one : int list} |- (1 :: one) : int list 5/11/2018

{one : int list} |- (1 :: one) : int list Proof of 1 Application 3 4 {one : int list} |- {one : int list} |- ((::) 1): int list int list one : int list {one : int list} |- (1 :: one) : int list 5/11/2018

Proof of 3 Constants Rule Constants Rule {one : int list} |- {one : int list} |- (::) : int  int list int list 1 : int {one : int list} |- ((::) 1) : int list  int list 5/11/2018

{one : int list} |- one:int list Proof of 4 Rule for variables {one : int list} |- one:int list 5/11/2018

Proof of 2 5 {x:int; one : int list} |- Constant fun y -> (x :: y :: one)) {one : int list} |- 2:int : int  int list {one : int list} |- (let x = 2 in fun y -> (x :: y :: one)) : int  int list 5/11/2018

{x:int; one : int list} |- fun y -> (x :: y :: one)) Proof of 5 ? {x:int; one : int list} |- fun y -> (x :: y :: one)) : int  int list 5/11/2018

{x:int; one : int list} |- fun y -> (x :: y :: one)) Proof of 5 ? {y:int; x:int; one : int list} |- (x :: y :: one) : int list {x:int; one : int list} |- fun y -> (x :: y :: one)) : int  int list 5/11/2018

{x:int; one : int list} |- fun y -> (x :: y :: one)) Proof of 5 6 7 {y:int; x:int; one:int list} {y:int; x:int; one:int list} |- ((::) x):int list int list |- (y :: one) : int list {y:int; x:int; one : int list} |- (x :: y :: one) : int list {x:int; one : int list} |- fun y -> (x :: y :: one)) : int  int list 5/11/2018

Proof of 6 Constant Variable {…} |- (::) : int int list int list {…; x:int;…} |- x:int {y:int; x:int; one : int list} |- ((::) x) :int list int list 5/11/2018

Proof of 7 Pf of 6 [y/x] Variable {y:int; …} |- ((::) y) {…; one: int list} |- :int list int list one: int list {y:int; x:int; one : int list} |- (y :: one) : int list 5/11/2018

Curry - Howard Isomorphism Type Systems are logics; logics are type systems Types are propositions; propositions are types Terms are proofs; proofs are terms Function space arrow corresponds to implication; application corresponds to modus ponens 5/11/2018

Curry - Howard Isomorphism Modus Ponens A  B A B Application  |- e1 :     |- e2 :   |- (e1 e2) :  5/11/2018

Mia Copa The above system can’t handle polymorphism as in OCAML No type variables in type language (only meta-variable in the logic) Would need: Object level type variables and some kind of type quantification let and let rec rules to introduce polymorphism Explicit rule to eliminate (instantiate) polymorphism 5/11/2018