Download presentation
Presentation is loading. Please wait.
Published byBuck Nelson Modified over 9 years ago
1
Types and Programming Languages Lecture 3 Simon Gay Department of Computing Science University of Glasgow 2006/07
2
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!)
3
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.
4
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:
5
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
6
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.
7
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.
8
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.
9
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.
10
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.
11
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.
12
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.
13
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?
14
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.
15
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.
16
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
17
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.
18
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:
19
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 ==.
20
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.
21
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.
22
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 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.
23
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.
24
2006/07Types and Programming Languages Lecture 3 - Simon Gay24 Reading Pierce: 3.3 Exercises Pierce: 3.2.4, 3.2.5, 3.5.5, 3.5.13, 3.5.14, 3.5.16, 3.5.17
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.