Types and Programming Languages Lecture 3 Simon Gay

Types and Programming Languages Lecture 3 Simon Gay Department of Computing Science University of Glasgow 2006/07 Types and Programming Languages Lecture 3 - Simon Gay

Avoiding run-time errors We will say that e Expr is valid if whenever it reduces to a stuck expression s, s is a value. Let Valid be the set of all valid expressions: Valid Expr. In fact, Valid Expr. (If Valid = Expr: no problem!) The Simple Expression Language is so simple that given e Expr we can work out whether or not e Valid simply by reducing e until we get stuck (which is bound to happen) and then examining the stuck expression. Exercise: why doesn’t this work in real programming languages? 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 2

Avoiding run-time errors We would like to define a set of safe expressions, Safe Expr, such that • given an expression e we can work out whether or not e Safe without reducing e • Safe Valid, so that if e Safe then e is valid (has no run-time errors) • we expect that Safe Valid but we want to make sure that the gap between Safe and Valid is not too large: if we adopt the principle of rejecting unsafe expressions, then we don’t want to reject too many valid expressions by mistake. The idea is to define a type system, and then Safe will be the set of expressions which are accepted by the typechecker. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 3

Types The idea for defining Safe is to classify the types of values: true : bool false : bool v : int if v is an integer literal and specify the operand result types of each operator. Addition: if e : int and f : int then e+f : int as an inference rule: 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 4

Types Similarly: What about the conditional? • the condition must have type bool • we can only give a type to the whole expression if both branches have the same type The obvious rule: but what about: stands for int or bool 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 5

Summary: type system true : bool false : bool v : int if v is an integer literal (T-Plus) (T-Eq) (T-And) (T-If) Notice that the rules are syntax directed. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 6

Typing derivations A typing derivation shows how the typing rules justify assigning a type to a particular expression. The derivation has a tree structure. Reading from the leaves to the root shows how we can build a derivation of a typed expression. Reading from the root to the leaves shows how we can check that a given typed expression is derivable, or even infer (deduce) the type (if it exists) of a given untyped expression. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 7

Type checking Example: is 2+(3==4): int derivable? To have 2+(3==4): int we need 2: int and 3==4: int by T-Plus. We have 2: int but the only possible typing for 3==4 is 3==4: bool if 3: int and 4: int (by T-Eq). So 2+(3==4): int is not derivable. Exercise: show a derivation for (1+2)+(if false then 3 else 4): int. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 8

Type inference Example: what is the type, if any, of if true then 2 else 3 ? By T-If, if we have true: bool and if, for some type T, we have 2: T and 3: T, then we have if true then 2 else 3: T. We do have true: bool; also 2: int and 3: int. So T=int. Therefore if true then 2 else 3: int. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 9

Safe expressions and valid expressions Recall that Valid is the set of expressions which never reduce to a stuck expression unless that stuck expression is a value. This is a semantic definition. The purpose of introducing the type system was to define This is a syntactic definition and we can easily check whether or not a given expression is safe. We must prove that Safe Valid. Exercise: why shouldn’t we expect Safe = Valid ? Find a valid expression which is not safe. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 10

Proving that Safe Valid The idea is: 1. prove that if e Safe and e e’ then e’ Safe. 2. prove that if e Safe and e is stuck then e is a value. Then if we start with any safe expression e and reduce it until it gets stuck: safe we know that every subsequent expression is safe, including the stuck expression s. Therefore s must be a value. This means that e is valid. The argument applies to any safe e, so every safe expression is valid. In other words, Safe Valid. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 11

1. Type preservation We need to prove that if e Safe and e e’ then e’ Safe. In fact we prove something stronger: if e: T and e e’ then e’: T. This is called a type preservation theorem or sometimes, for historical reasons, a subject reduction theorem. Let’s try to prove the type preservation theorem by analyzing the possible forms of e, in each case looking at the possibilities for e e’, and using the fact that e: T. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 12

Type preservation 1. If e is a value then e has no reductions: nothing to prove. 2. If e is a+b then we have a+b: int, a: int and b: int. There are three possible kinds of reduction. i. a+b a’+b because a a’. Then because a: int we would like to say that a’: int, and then a’+b: int. ii. a+b’ because b b’. Then because b: int we would like to say that b’: int, and then a+b’: int. iii. a and b are integer literals and a+b c where c is also an integer literal. Then c: int. Is this reasoning valid? 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 13

Proof by induction We are trying to prove that if e: T and e e’ then e’: T. During the proof we consider the case when e is of the form a+b. At this point we want to assume that if a: T and a a’ then a’: T, and similarly for b. This might seem to be circular reasoning - we are assuming the thing that we are trying to prove - but in fact we are doing a proof by induction, and our reasoning is sound as long as we only assume it for subexpressions of the expression under consideration. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 14

Proof by induction In general, to prove a property P of expressions: • prove P(v) for all values v • prove P(e+f) assuming P(e) and P(f) • prove P(e&f) assuming P(e) and P(f) • prove P(e==f) assuming P(e) and P(f) • prove P(if c then e else f) assuming P(c) and P(e) and P(f) This is the induction principle for expressions. In our specific example, the property we are proving is P(e): if e: T and e e’ then e’: T. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 15

Inductive definitions and induction principles Whenever we have an inductive definition we have an induction principle. The grammar defining expressions: e : : = v | e + e | e == e | e & e | if e then e else e can be recast as an inductive definition of the set Expr: v Expr 2006/07 if v is a value Types and Programming Languages Lecture 3 - Simon Gay 16

More familiar induction: positive integers The set N of positive integers has the inductive definition and a corresponding induction principle. Let P be a property of positive integers. If • P(0) is true, and • for all k N, we can prove P(k+1) by assuming P(k) then for all n N, P(n) is true. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 17

Example: proof by induction on positive integers Standard example: prove that for all n N, (this is P(n)) First prove P(0) (known as the base case): both sides are 0. Next, for a general k, prove P(k+1) assuming P(k). This is known as the induction step or the step case, and the assumption P(k) is known as the induction hypothesis. Assume P(k): Therefore: 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 18

Type preservation Now we can prove this properly. We know what property P is. • Prove P(v) for all values v: already done • Prove P(e+f) given P(e) and P(f): we have e+f: int, e: int, f: int. There are three possible kinds of reduction. i. e+f e’+f because e e’. By the induction hypothesis P(e), e’: int. Therefore e’+f: int. ii. e+f’ because f f’. By the induction hypothesis P(f), f’: int. Therefore e+f’: int. iii. e and f are integer literals and e+f g where g is also an integer literal. Then g: int. • Prove P(e&f) given P(e) and P(f): similar to +. • Prove P(e==f) assuming P(e) and P(f): similar to + and &. Exercise: spell out the details for & and ==. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 19

Type preservation • Prove P(if c then e else f) given P(c) and P(e) and P(f). If if c then e else f: T then c: bool, e: T, f: T. There are three possible kinds of reduction. i. if c then e else f if c’ then e else f because c c’. By the induction hypothesis P(c), c’: bool. Therefore if c’ then e else f: T. ii. c is true and if c then e else f e. We know that e: T. iii. c is false and if c then e else f f. We know that f: T. This completes the proof of type preservation. The theorem expresses the fact that types classify expressions according to their ultimate values: if e: T then evaluating e will eventually result in a value of type T. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 20

Safe (typable) stuck expressions are values Put another way: a typable expression can’t be stuck unless it is a value. We prove it by induction, but this time we can be less formal. Consider the syntactic forms of an expression e and assume that it is typable. For any subexpression f of e, assume that if f is stuck then f is a value (we will know that f is typable). 1. e could be an integer or boolean literal, so it is stuck but also a value. 2. e could be a+b. In this case a: int and b: int. If a a’ then a+b a’+b and a+b is not stuck. If a is stuck then by the induction hypothesis a value. If so, then if b b’ then a+b’ and a+b is not stuck. If b is also stuck then again b is a value. If so then a+b reduces to the sum of a and b, so it is not stuck. Therefore a typable expression of the form a+b is not stuck. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 21

2. Safe (typable) stuck expressions are values 3. If e is a&b or a==b then the argument is similar to case 2. 4. If e is if c then f else g then c: bool and for some T, f: T and g: T. If c is not stuck then e is not stuck. If c is stuck then by the induction hypothesis it is a value, either true or false. So either e f or e f, and e is not stuck. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 22

What have we done? We have defined a set of expressions, Expr, and a reduction relation on Expr. Valid Expr consists of the expressions which reduce without getting stuck. In fact, Valid Expr. In realistic programming languages the question e Valid ? is undecidable. We have used a type system to define Safe Expr , a set of safe (typable) expressions. Typechecking is easy. We have proved that Safe Valid by combining a type preservation theorem and a theorem about stuck expressions. Safe Valid is called soundness of the type system. In fact Safe Valid. If we had Safe = Valid then the type system would be complete but this is usually not possible. 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 23

Reading Pierce: 3. 3 Exercises Pierce: 3. 2. 4, 3. 2. 5, 3. 5. 13, 3. 5. 14, 3. 5. 16, 3. 5. 17 2006/07 Types and Programming Languages Lecture 3 - Simon Gay 24