a type-checking algorithm

Catriel Beeri Pls/Winter 2004/05 types 1

A type-checking algorithmThe task:

(since we start with empty H, why is the goal not just E?)

The rule set (revisited next page) is algorithmic:The rules are syntax-directed

– For each expression, a unique potentially applicable rule– For goals in body of a proper rule:

• Environment determined by head goal environment • Expression is a direct sub-expression of head goal

expression

goal solutiGiven , ( ) find ( )

such that | : holds

onH E

H E


| : typeOf((c c)on st) H c

1 1

1 1

| : ,..., | :

| ( ,..., ) : ( ,.(tuple

..,)

)n n

n n

H e H eH e e

1 2

1 2

| :(appl

| :

| :ic)

H e H eH e e

1 2 3

1 2 3

| : bool | : | :

| if then else(if

:)

H e H e H e

H e e e

, (var) | : :H x x


{ : } | :

| : .( )

:H x e

H x e

1 1

1 1 1

{ : ,..., : } | :

| ( : ,..., : ). : ( ,...,( -mult)

)n n

n n n

H x x eH x x e

1 1

1 1 1

| : , 1.. { : ,..., : } | :

| let ,..., in : ( ,..

(let

., )

)

i i n n

n n n

H e i n H x x eH x e x e e


For deriving an algorithm, we make explicit all conditions in the rules:

(the exists is not a problem here --- why?)

Why are the conditions placed in these positions?

1 1 2 2

1

1 2

2

| : | :

(a

| :

pplic-expl

( )

)

H e H eH e e

1 1 2 2 31 23

1 2 3

3

2

| : | : | :

| ibool

f

(if-ex

then else :

pl)

H e H e H eH e e e


The algorithm:

1 i 1 n

1 2 1 1 2 2

free var e

( , ) = case of

c (c)

( ) ( ( ) raise )

(e ,... ) ( , ) ...

( , ), ( , )

if rror

Type

typeOf

Type

Ty

le

pe T

t in

let ype

n i

H e e

x H x x dom H

e H e

e e H e H e

1 2

raise t

in if

yp

then

e e mismatch in pse apl


1 2 3

1 2 3 2

let

in if and t

if ( , ) , 1..3

bool

raise type mismtach in if

Type

Type

hen

else

: . let ( {

i ie e e H e i

x e H

: }, ) in x e

Multi-arg functions -- left to you


1 1

i

1 1

let ,..., in

( , ), 1..

Type

Type ( { : ,..., : }, ) τ

τ

let

and

in

n n

i

n n

x e x e e

H e i n

H x x e

s

s s

= = Þ

= Î

®Å =

Certain obvious optimization(s) are left to you


For an expression w/o let the algorithm works in two stages:

• From root of expression to leaves, determining the type environment for each sub-expression

• From leaves to root, determining types of sub-expressions H

H2H1

τ

2τ1τ


For a let expression (or sub-expression):• Apply algorithm to defining expressions, to obtain

their types,• Use these types in determining type environment

for body

1s

H

ns

let

1 1{ : ,..., : }n nH x xs s®Åτ


Claim: [correctness of algorithm (w.r.t. rules)]

Proof: by induction on E

Since a well-typed expression has at most one type under an environment, the algorithm returns a unique type, or fails

For a closed program E, the initial call is

( , ) iff Typ |e :H E H E

Type( , )E


Comment:

Type-checker is the component that discovers missing declarations -- free var error

Example: (assume this entered as 1st line in an ocaml session)

let f = fun n if n=0 then 1 else n*f(n-1);


On implementation:

A compiler constructs a symbol table: • Types for declared variables (from the declarations)

• Hierarchical organization – reflects region hierarchy

Type-checking of program phrase performed with respect to right place in the table.


On the correctness of the rules

Specifically:• Never generates a run-time type error • Halts only if reaches an extended value (progress)Together: type safety (some use safety only for the 1st)

We prove also:• Never applies rule to argument of wrong type

(according to the type declared for the function)

In the typed language, this is also a type error

( )

A well-typed program never goes wrong


We prove using transition semantics

A problem:

We deal with two worlds (TFL, FL) each with only some of the concepts.

TFL:

FL:

erase

Typed expressions Typing relationWell typed

No Transition semanticsRun-time type errors

Transition semanticsRun-time type errors

Untyped expressions No typings


The solution: a transition relation for TFL:same as but on typed expressions, except

the diagram (almost) commutes:(except when?)

progress holds for this language as well! Now, transitions, run-time errors apply to upper level -- TFL

t

t

t

( ) ( : . ) [ / ] when v:

( : . ) otherwise

x e v v x e

x e v ER,

t '

'

erase erase

E E

E E


Observation:

A run-time type error w.r.t. t is not well-typed:

•

•

• v1 v2, where v1 is not an operation, nor a function, (hence (canonical forms) its type is not a function type)

• If v e2 e3 where v is a non-booleanThis covers all r-t type errors that have a transition to ER

Corollary:

An expression that contains a run-time type error

(even not as its selected sub-expression) is not well-typed

where is not of 's input typeo v v o

( . ) where is not of the function input typex e v v


Assume WT(E), but E’s execution generates a type-error

Q: How do we show this is impossible?

A: we prove a type preservation property

This property is the key to type safety How is it related to the informal intro to static type checking?

*tThus | : , ', and ' i nos wet ll-typedH E E E E

tIf an | : ' | ' : d thenH E E E H E


A comment:

We prove type preservation for regular expressions only; ER has no type

(alternatives?)

ER


Theorem [Type preservation/ Subject reduction]

(where E’ is not ER)

Proof : induction on selection path of E – this path never goes to a lambda, hence H is fixed

We show first the induction step (easier)

then the basis (redexes)

tIf an | : ' | ' : d thenH E E E H E


Induction step: case of E• E= E1 E2 E’1 E2 (case for E2 is symmetric)

• If – a step on the test, similar • Tuple – a step on a component, similar• Let – a step on a defining expression, similar

Q: Where did we use inversion above?

| : ( | 1: , | 2 : )H E H E H E

induction hypthesis: | '1:H E

hence | '1 2 :H E E


Basis: (redexes)•

•

t

(when ( ) )

(assumption about peOf t )y

( ), where

(O) = , and | : then |

t

( ) : hol

ype

d

O

s

f

O

O

O f V

O V f V

H V

H f V ER

1 2, where | 1 2 :

(hence | 1: , | 2 : )

v v H v v

H v H v

if 2 3, is boolean

claim is obvious

v e e v


t

(relatively)

(substitution, but for several variables)

( : . ) [ / ] ( )

the more difficult case, next page

multi-

substitution st

arg functions - same

epx E V V x E

1 1 1 1 t 1 1

(again substitution, but for several variables)

let ,..., let in E [ / ,..., / ]n nx V x V V x V x E= = ®g


The “difficult” case: function application

Lemma: [type preservation under substitution]

Intuitively simple, formally by induction on E

End of proof of type preservation

| ( : . ) : implies

(i) | ( : . ) :

hence (*) { : } | :

(ii) | :

H x E V

H x E

H x E

H V

{ : } | : , and if

the

| :

| [n / ] :

H x E H V

H V x E


Back to original goal:

Corollary (of preservation thm):[correctness of type rules]

Corollary:

*t

(when ' is not ER)

If H | : and ' then H | ' :

Hence ' is not a run-time type error

the execution of will not generate a type error

E

E E E E

E

E

*typeIf | : and ( : . ) [ / ]

then | :

(rule ( ) is applied only to type-correct arguments)

H E E x D V V x D

H V


Now, transfer correctness to the FL setting

Corollary:

If E (in TFL) is well-typed, then • the FL execution of erase(E) will not generate a

type error

The execution may generate other errors, or be infinite

(one reason natural semantics has not been used for the correctness proof)


Discussion of TFL’s type system

The type system is monomorphic• Each literal (number, boolean, operation name) has unique type

(transferred to type checker by axiom (const))

• Variables have unique types (by declarations)\

(transferred to type checker by axiom (var))

• Each well-typed expression has a unique type (induction on expressions)

• Each value (including tuples, functions) has a unique type (if its expression is well-typed)

But, are all our assumptions satisfied in real pl’s?


• The operation name + may be associated with two operations (on int, real) (ad-hoc polymorphism)

• The operation = has a polymorphic type:

(an eq-type)

• The constant nil (empty list) (not yet introduced)

has a polymorphic type

Q: is the type system still monomorphic?

In what sense?

bool (provided does not contain )

( )list


On type equality (equivalence)

The type checker uses type equality tests (where?)

How is type equality defined?• By structure of the types --structural equivalence

Types are equivalent if they have same structure

• By name -- name equivalence– Type names are associated (once) to some structure

– Types are equivalent only if they have same name

Type systems that use `by name’ are called nominal

They include: Pascal, Java


Comments and Discussion

Dynamic typing:• Only values (operations & functions included) are typed• Type compatibility determined at run-time (‘last minute’)

• Types are general: (n-ary) function, list,

• Functions can be applied to all arguments of right arity

(define id (lambda (x) x) (id 3) (id id)

• Collections may be heterogeneous


Static - monomorphic:• Values are typed (most, especially functions, are uni-typed)

• Cells are (uni-)typed (not seen in TFL)

– Cells can be assigned only values of their type

• variables, expressions, are statically typed (most expressions are uni-typed)

• Types must be detailed– Operations, functions: both in and out types

functions can be applied only to their in type

– Collections: include the element type, hence

must be homogeneous (& uni-typed) (exception: records)

• Conditional expressions are conservatively typed


Pro and Cons

Dynamic:

For : flexibility:• non-restrictive types, • no fixed types for cells, expressions, …

Against : • increased overhead

– extra storage,

– extra run-time,

• reduced safety (late discovery of many errors)


Static (mono):

For :• Increased performance

– Reduced storage (no tags)

(but modern pl’s may include tags for other reasons)

– Less run-time checks

– Data structure storage and access optimized by type

• increased safety – Improved documentation

– Early discovery of many errors


Against : • Conservative checking, more type errors

some ok programs are rejected • Monomorphism, restrictive types

(uni-typed functions, homogeneous collections)

reduced flexibility, non-generic programs, lack of reusability

Examples: one needs to write• Uni-typed append functions, one for each type

• Uni-typed search tree procedures for each type

Since parameters must be declared, this cannot be avoided


Many users do not accept these restrictions, and prefer dynamically typed language (e.g. scripting pls)

What are the possible solutions?The pl research/development community offers:

Polymorphic type systems:


Kinds of polymorphic type systems:• Parametric polymorphism (a-la ML)• Values, in particular functions, have many types, are reusable• Sub-type polymorphism (a-la OO)

– Values, in particular functions have many types,

are reusable– Collections can have elements of many types

In last two decades, approaches to merging the two have been developed

war between the dynamic and static schools is still active


What next?

• We extend FL and TFL with various constructs: recursion, cells, … (depends on available time)

For each, we examine semantics and typing

• We proceed to the environment model

In the future, we discuss ML-style parametric polymorphism, hopefully also sub-type polymorphism

a type-checking algorithm

Documents

type environment

type safety

function type

unique type

static type checking

region hierarchy type

runtime type error halts

type errora welltyped