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

Types and Programming Languages Lecture 3 - Simon Gay2 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: 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? Valid  Expr. In fact, Valid  Expr. (If Valid = Expr: no problem!)

2006/07Types and Programming Languages Lecture 3 - Simon Gay3 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/07Types and Programming Languages Lecture 3 - Simon Gay4 Types The idea for defining Safe is to classify the types of values: true : bool false : bool v : intif v is an integer literal and specify the operand and result types of each operator. Addition: if e : int and f : int then e+f : int as an inference rule:

2006/07Types and Programming Languages Lecture 3 - Simon Gay5 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/07Types and Programming Languages Lecture 3 - Simon Gay6 Summary: type system true : bool false : bool v : intif v is an integer literal (T-Plus) (T-And) (T-Eq)(T-If) Notice that the rules are syntax directed.

2006/07Types and Programming Languages Lecture 3 - Simon Gay7 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/07Types and Programming Languages Lecture 3 - Simon Gay8 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/07Types and Programming Languages Lecture 3 - Simon Gay9 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/07Types and Programming Languages Lecture 3 - Simon Gay10 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/07Types and Programming Languages Lecture 3 - Simon Gay11 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. safe 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/07Types and Programming Languages Lecture 3 - Simon Gay12 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/07Types and Programming Languages Lecture 3 - Simon Gay13 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  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/07Types and Programming Languages Lecture 3 - Simon Gay14 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/07Types and Programming Languages Lecture 3 - Simon Gay15 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/07Types and Programming Languages Lecture 3 - Simon Gay16 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  Exprif v is a value

2006/07Types and Programming Languages Lecture 3 - Simon Gay17 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/07Types and Programming Languages Lecture 3 - Simon Gay18 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/07Types and Programming Languages Lecture 3 - Simon Gay19 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  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/07Types and Programming Languages Lecture 3 - Simon Gay20 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/07Types and Programming Languages Lecture 3 - Simon Gay21 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 is a value. If so, then if b  b’ then a+b  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/07Types and Programming Languages Lecture 3 - Simon Gay22 2. Safe (typable) stuck expressions are values 3. If e is a&b or a==b then the argument is similar to case 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/07Types and Programming Languages Lecture 3 - Simon Gay23 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/07Types and Programming Languages Lecture 3 - Simon Gay24 Reading Pierce: 3.3 Exercises Pierce: 3.2.4, 3.2.5, 3.5.5, , , ,