1 / 24

Types and Programming Languages

Types and Programming Languages. Lecture 3. Simon Gay Department of Computing Science University of Glasgow. 2006/07. 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.

elinor
Download Presentation

Types and Programming Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Avoiding run-time errors We will say thate  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? Types and Programming Languages Lecture 3 - Simon Gay

  3. 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 note Safewithout reducinge • 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. Types and Programming Languages Lecture 3 - Simon Gay

  4. 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 and result types of each operator. Addition: if e : int and f : int then e+f : int as an inference rule: Types and Programming Languages Lecture 3 - Simon Gay

  5. stands for int or bool 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: Types and Programming Languages Lecture 3 - Simon Gay

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

  7. 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. Types and Programming Languages Lecture 3 - Simon Gay

  8. 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. Types and Programming Languages Lecture 3 - Simon Gay

  9. 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. Types and Programming Languages Lecture 3 - Simon Gay

  10. 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. Types and Programming Languages Lecture 3 - Simon Gay

  11. 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 safe safe 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. Types and Programming Languages Lecture 3 - Simon Gay

  12. 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. Types and Programming Languages Lecture 3 - Simon Gay

  13. 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:intwe would like to say that a’:int, and then a’+b:int. ii. a+ba+b’ because bb’. Then because b:intwe 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? Types and Programming Languages Lecture 3 - Simon Gay

  14. 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. Types and Programming Languages Lecture 3 - Simon Gay

  15. 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. Types and Programming Languages Lecture 3 - Simon Gay

  16. 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 if v is a value Types and Programming Languages Lecture 3 - Simon Gay

  17. 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. Types and Programming Languages Lecture 3 - Simon Gay

  18. 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: Types and Programming Languages Lecture 3 - Simon Gay

  19. 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 ==. Types and Programming Languages Lecture 3 - Simon Gay

  20. 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. Types and Programming Languages Lecture 3 - Simon Gay

  21. 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. Types and Programming Languages Lecture 3 - Simon Gay

  22. 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. Types and Programming Languages Lecture 3 - Simon Gay

  23. 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. Types and Programming Languages Lecture 3 - Simon Gay

  24. 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 Types and Programming Languages Lecture 3 - Simon Gay

More Related