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

Types and Programming Languages

  • Upload
    elinor

  • View
    39

  • Download
    1

Embed Size (px)

DESCRIPTION

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. - PowerPoint PPT Presentation

Citation preview

Page 1: Types and Programming Languages

Types and Programming Languages

Lecture 3

Simon GayDepartment of Computing Science

University of Glasgow

2006/07

Page 2: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 2

Avoiding run-time errors

We will say that e Expr is valid if whenever it reduces to astuck expression s, s is a value.

Let Valid be the set of all valid expressions:}|{ valid is eExpreValid

The Simple Expression Language is so simple that givene Expr we can work out whether or not e Valid simply byreducing e until we get stuck (which is bound to happen) andthen 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!)

Page 3: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 3

Avoiding run-time errorsWe 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 theset of expressions which are accepted by the typechecker.

Page 4: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 4

Types

The idea for defining Safe is to classify the types of values:

true : boolfalse : boolv : 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:

intfeintfinte

:::

conclusionhypothesishypothesis 21

Page 5: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 5

Types

Similarly:boolfe

boolfboole:&

::boolfe

intfinte:

::

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:

intfelseethencifintfinteboolc

::::

but what about:

boolfelseethencifboolfbooleboolc

::::

TfelseethencifTfTeboolc

::::

stands forint or bool

Page 6: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 6

Summary: type system

true : boolfalse : boolv : int if v is an integer literal

intfeintfinte

:::

boolfeboolfboole

:&::

(T-Plus) (T-And)

boolfeintfinte

:::

(T-Eq) TfelseethencifTfTeboolc

::::

(T-If)

Notice that the rules are syntax directed.

Page 7: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 7

Typing derivations

A typing derivation shows how the typing rules justify assigninga type to a particular expression.

If-TintelsethenifPlusTint

intintPlusTintintintEq-Tbool

intint

:213221:21

:2:1:32

:3:2:21

:2:1

The derivation has a tree structure.

Reading from the leaves to the root shows how we can build aderivation of a typed expression.

Reading from the root to the leaves shows how we can checkthat a given typed expression is derivable, or even infer(deduce) the type (if it exists) of a given untyped expression.

Page 8: Types and Programming Languages

2006/07 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==4is 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.

Page 9: Types and Programming Languages

2006/07 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:booland 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.

Page 10: Types and Programming Languages

2006/07 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 toa stuck expression unless that stuck expression is a value.This is a semantic definition.

The purpose of introducing the type system was to define}::|{ booleorinteExpreSafe

This is a syntactic definition and we can easily check whetheror not a given expression is safe.

We must prove that Safe Valid.

Exercise: why shouldn’t we expect Safe = Valid ? Find a validexpression which is not safe.

Page 11: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 11

Proving that Safe Valid

The idea is:1. prove that if e Safe and ee’ 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 itgets stuck:

seee 21

safe

we know that every subsequent expression is safe, including thestuck expression s. Therefore s must be a value.

safe safe 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.

Page 12: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 12

1. Type preservation

We need to prove that if e Safe and ee’ then e’ Safe.In fact we prove something stronger: if e:T and ee’ then e’:T.This is called a type preservation theorem or sometimes, forhistorical reasons, a subject reduction theorem.

Let’s try to prove the type preservation theorem by analyzing thepossible forms of e, in each case looking at the possibilities foree’, and using the fact that e:T.

Page 13: Types and Programming Languages

2006/07 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+ba’+b because aa’. Then because a:int we would like to say that a’:int, and then a’+b:int. ii. a+ba+b’ because bb’. 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+bc where c is also an integer literal. Then c:int.

Is this reasoning valid?

Page 14: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 14

Proof by inductionWe are trying to prove that if e:T and ee’ then e’:T. During theproof we consider the case when e is of the form a+b. At this point we want to assume that if a:T and aa’ then a’:T, andsimilarly for b.

This might seem to be circular reasoning - we are assuming thething that we are trying to prove - but in fact we are doing a proofby induction, and our reasoning is sound as long as we onlyassume it for subexpressions of the expression underconsideration.

Page 15: Types and Programming Languages

2006/07 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 isP(e): if e:T and ee’ then e’:T.

Page 16: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 16

Inductive definitions and induction principles

Whenever we have an inductive definition we have aninduction 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

ExprfeExprfExpre

ExprfeExprfExpre

&ExprfeExprfExpre

ExprfelseethencifExprfExpreExprc

Page 17: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 17

More familiar induction: positive integers

The set N of positive integers has the inductive definition

N1nNn

N0

and a corresponding induction principle.

Let P be a property of positive integers. If• P(0) is true, and• for all kN, we can prove P(k+1) by assuming P(k)then for all nN, P(n) is true.

Page 18: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 18

Example: proof by induction on positive integers

Standard example: prove that for all nN,

2)1(210 nnn (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 knownas the induction step or the step case, and the assumption P(k)is known as the induction hypothesis.Assume P(k):

2)1(210 kkk

Therefore: 12

)1()1(210 kkkkk

2)2)(1(

2)1(2

2)1( kkkkk

Page 19: Types and Programming Languages

2006/07 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+fe’+f because ee’. By the induction hypothesis P(e), e’:int. Therefore e’+f:int. ii. e+fe+f’ because ff’. By the induction hypothesis P(f), f’:int. Therefore e+f’:int. iii. e and f are integer literals and e+fg 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 ==.

Page 20: Types and Programming Languages

2006/07 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 fif c’ then e else f because cc’. 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 fe. We know that e:T. iii. c is false and if c then e else ff. We know that f:T.

This completes the proof of type preservation. The theoremexpresses the fact that types classify expressions according totheir ultimate values: if e:T then evaluating e will eventually resultin a value of type T.

Page 21: Types and Programming Languages

2006/07 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 isa value. We prove it by induction, but this time we can be lessformal. Consider the syntactic forms of an expression e andassume that it is typable. For any subexpression f of e, assumethat 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.

Page 22: Types and Programming Languages

2006/07 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 ef or ef, and e is not stuck.

Page 23: Types and Programming Languages

2006/07 Types and Programming Languages Lecture 3 - Simon Gay 23

What have we done?

We have defined a set of expressions, Expr, and a reductionrelation on Expr.

Valid Expr consists of the expressions which reduce withoutgetting stuck. In fact, Valid Expr. In realistic programminglanguages the question eValid ? is undecidable.

We have used a type system to define Safe Expr , a set ofsafe (typable) expressions. Typechecking is easy.

We have proved that Safe Valid by combining a typepreservation 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 systemwould be complete but this is usually not possible.

Page 24: Types and Programming Languages

2006/07 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