Type Checking
-
Upload
audrey-tate -
Category
Documents
-
view
30 -
download
0
description
Transcript of Type Checking
Plan
• Motivation (Chapter 1)
• Untyped Arithmetic Expressions (Chapter 3)
• Typed Arithmetic Expressions (Chapter 8)
• Untyped Lambda Calculus (Chapter 5)
• Typed Lambda Calculus (Chapter 9)
• Extensions
Challenges of Program Verification
• Specification of software behavior
• Reasoning about logical formulas
• The annotation burden• The dynamic nature of
software
• Automatically infer safe invariants from the code
• Concentrate on very simple properties with lightweight annotations
1997 Mars Rover Loses Contact
1999 Mars Climate Orbiter is Lost
1999 Mars polar Lander is lost
2004 Mar rover freezes
August 2005As a Malaysia Airlines jetliner cruised from Perth, Australia, to Kuala Lumpur, Malaysia, one evening last August, it suddenly took on a mind of its own and zoomed 3,000 feet upward. The captain disconnected the autopilot and pointed the Boeing 777's nose down to avoid stalling, but was jerked into a steep dive. He throttled back sharply on both engines, trying to slow the plane. Instead, the jet raced into another climb. The crew eventually regained control and manually flew their 177 passengers safely back to Australia.
Investigators quickly discovered the reason for the plane's roller-coaster ride 38,000 feet above the Indian Ocean. A defective software program had provided incorrect data about the aircraft's speed and acceleration, confusing flight computers. August 2005
Type Systems
• A tractable syntactic method for proving absence of certain program behaviors by classifying phrases according to the kinds they compute
• Examples– Whenever f is called, its argument must be integer
– The arguments of f are not aliased
– The types of dimensions must match
– …
Static Type Checking
• Performed at compile-time• Conservative (sound but incomplete)
– if <complex test> then 5 else <type error>• Usually limited to simple properties
– Prevents runtime errors– Enforce modularity– Protects user-defined abstractions– Allows tractable analysis
• Properties beyond scope (usually)– Array out of bound– Division by zero– Non null reference
Error detection
• Early error detection– Logical errors– Interface errors– Dimension analysis– Effectiveness also depends on the programmer– Can be used for code maintenance
Abstraction
• Types define interface between different software components
• Enforces disciplined programming
• Ease software integration
Language Safety
• A safe programming language protects its own abstraction
• Can be achieved by type safety
Statically vs. Dynamically Checked Languages
Statically Checked
Dynamically Checked
Safe ML, Haskel, Java
Lisp, Scheme, Perl
Unsafe C, C++
Eiffel, 1989
Cook, W.R. (1989) - A Proposal for Making Eiffel Type-Safe, in Proceedings of ECOOP'89. S. Cook (ed.), pp. 57-70. Cambridge University Press.
Betrand Meyer, on unsoundness of Eiffel: “Eiffel users universally report that they almost never run into such problems in real software development.”
Efficiency
• Compilers can used types to optimize computations
• Pointer scope (Titanium)
• Region inference
Language Design
• Design the programming language with the type system
• But types incur some notational overhead
• Implicit vs. explicit types– The annotation overhead
Untyped Arithmetic Expressionst ::= terms
true constant true
false constant false
if t then t else t conditional
0 constant zero
succ t successor
pred t predecessor
izzero t zero test
if false then 0 else 1 1
iszero (pred (succ 0)) true
Untyped Arithmetic Expressionst ::= terms
true constant true
false constant false
if t then t else t conditional
0 constant zero
succ t successor
pred t predecessor
izzero t zero test
succ true type error
if 0 then 0 else 0 type error
SOS for Booleanst ::= terms
true constant true
false constant false
if t then t else t conditional
v ::= values
true
false
if true then t1 else t2 t1 (E-IFTRUE)
if false then t1 else t2 t2 (E-IFFALSE)
t1 t’1
if t1 then t1 else t2
if t’1 then t1 else t2
(E-IF)
t1 t’1
SOS for Numberst ::= terms
0 constant zero
succ t successor
pred t predecessor
iszero t zero test
v ::= values
true true value
false false value nv numeric values
nv ::= numeric values
0 zero value
succ nv successor value
t1 t’1
succ t1 succ t’1 (E-SUCC)
pred 0 0 (E-PREDZERO)
pred (succ nv1) nv1 (E-PREDSUCC)
iszero 0 true (E-ISZEROZERO)
iszero (succ nv1) false (E-ISZEROSUCC)
t1 t’1
t1 t’1
pred t1 pred t’1 (E-PRED)
t1 t’1
iszero t1 iszero t’1 (E-ISZERO)
Stuck Computations
• The goal of the type system is to ensure at compile-time that no stuck ever occurs at runtime
• Safety (soundness)– Progress: A well-typed term t never gets stuck
• Either it has value or there exists t’ such that t t’
– Preservation (subject reduction)• If well type term takes a step in evaluation, then the
resulting term is also well typed
Type Rules for BooleanT ::= types Bool type of Boolean
t : T
true : Bool (T-TRUE)
false : Bool (T-FALSE)
t1 : Bool t2 : T t3 : T
if t1 then t2 else t3 : T(T-IF)
Type Rules for NumbersT ::= types Nat type of Natural numbers
t : T
0 : Nat (T-ZERO)
t1 : Nat
succ(t1) : NatT-SUCC
t1 : Nat
pred(t1) : NatT-PRED
t1 : Nat
iszero(t1) : BoolISZERO
The Typing Relation
• Formally the typing relation is the smallest binary relation between terms and types – in terms of inclusion
• A term t is typable (well typed) if there exists some type T such that t : T
Inversion of the typing relation
• true : R R = Bool• false : R R = Bool
• if t1 then t2 else t3 : R t1: Bool, t2 : R, t3: R
• 0 : R R = Nat
• succ t1 : R R = Nat and t1 : Nat
• pred t1 : R R = Nat and t1 : Nat
• iszero t1 : R R = Bool and t1 : Nat
Uniqueness of Types
• Each term t has at most one type– If t is typable then
• its type is unique
• There is a unique type derivation tree for t
Safety
• Canonical Forms:– If v is a value of type Boolean then v =true or v=false– If v is a value of type Nat then v belongs to nv
• Progress: If t is well defined then either t is a value or for some t’: t t’
• Preservation: if t : T and t t’ then t’ : T
nv ::= numeric values
0 zero value
succ nv successor value
Untyped Lambda Calculust ::= terms
x variable
x. t abstraction
t t application
( x. x) ( x. x) ( x. x)
Syntactic Conventions
• Applications associates to left
• The body of abstraction extends as far as possible
Scope
• An occurrence of x is free in a term t if it is not in the body on an abstraction x. t – otherwise it is bound x is a binder
• FV: t P(Var) is the set free variables of t– FV(x) = {x}– FV( x. t) = FV(t) – {x}– FV (t1 t2) = FV(t1) FV(t2)
• Terms w/o free variables are combinators– Example: x. x
Operational Semantics( x. t12) t2 [x t2] t12 (-reduction)
[xs]x =s
[x s]y=y if y x
[x s ] (y. t1) = y. [x s ] t1 if y x and yFV(s)
[x s ] (t1 t2) = ([x s ] t1) ([x s ] t2)
( x. x) y y
( x. x ( x. x) ) (u r) u r ( x. x)
( x (y. x y)) (y z) ( x (w. x w)) (y z) w. y z w
Operational Semantics( x. t12) t2 [x t2] t12 (-reduction)
[xs]x =s
[x s]y=y if y x
[x s ] (y. t1) = y. [x s ] t1 if y x and yFV(s)
[x s ] (t1 t2) = ([x s ] t1) ([x s ] t2)
Evaluation orders:
•Full beta reduction
•Normal order
•Call by name
•Call by value
)x. x)((x. x)(z. (x. x) z))
Programming in the Lambda Calculus• Turing complete• Multiple arguments
(x, y). s = x. y.s• Church Booleans
– tru = t. f. t– fls =t. f. f– test =l. m. n. l m n– and = b. c. b c fls
• Pairs– pair = f. b. s. b f s– fst = p. p tru– snd = p. p fls
• Church Numerals– c0 = f. z. z– c1 =f. z. s z– c2 = f. z. s (s z)– c3 = f. z. s (s (s z))
• Divergence– omega= (x. x x) (x. x x)
Summary Lambda Calculus
• Powerful
• Useful to illustrate ideas
• But can be counterintuitive
• Usually extended with useful syntactic sugars
Simple Typed Lambda Calculust ::= terms
x variable
x: T. t abstraction
t t application
T::= types
T T types of functions
SOS for Simple Typed Lambda Calculus
t ::= terms
x variable
x: T. t abstraction
t t application
v::= values
x: T. t abstraction values
T::= types
T T types of functions
t1 t2
t1 t’1
t1 t2 t’1 t2
(E-APP1)
t2 t’2
t1 t2 t1 t’2
(E-APP2)
( x: T11. t12) t2 [x t2] t12 (E-APPABS)
t ::= terms
x variable
x: T. t abstraction
T::= types
T T types of functions
::= context
empty context
, x : T term variable binding
t : T
x : T x : T
(T-VAR)
, x : T1 t2 : T2
x : T1. t2 : T2 : T1 T2
(T-ABS)
t1 : T11 T12
t1 t2 : T12
(T-APP) t2 : T11
Type Rules
t ::= terms
x variable
x: T. t abstraction
t t application
true constant true
false constant false
if t then t else t conditional
T::= types
Bool Boolean type
T T types of functions
::= context
empty context
, x : T term variable binding
t : T
x : T x : T
(T-VAR)
, x : T1 t2 : T2
x : T1. t2 : T2 : T1 T2
(T-ABS)
t1 : T11 T12
t1 t2 : T12
(T-APP) t2 : T11
true : Bool (T-TRUE)
false : Bool (T-FALSE)
t1 : Bool t2 : T t3 : T
if t1 then t2 else t3 : T(T-IF)
Examples
• )x:Bool. x ) true
• if true then )x:Bool. x) else ) x:Bool. x)
• if true then )x:Bool. x) else ) x:Bool. y:Bool. x)
The Typing Relation
• Formally the typing relation is the smallest ternary relation on contexts, terms and types – in terms of inclusion
• A term t is typable in a given context (well typed) if there exists some type T such that t : T
Inversion of the typing relation
x : R x: R x : T1. t2 : R R = T1 R2 for some R2 with
t2 : R2
t1 t2 : R there exists T11 such that t1 : T11 R and t2 : T11
true : R R = Bool false : R R = Bool if t1 then t2 else t3 : R t1: Bool,
t2 : R, t3: R
Uniqueness of Types
• Each term t has at most one type in any given context– If t is typable then
• its type is unique
• There is a unique type derivation tree for t
Safety
• Canonical Forms:– If v is a value of type Boolean then v =true or v=false– If v is a value of type T1 T2 then v =x. T1. t2
• Progress: If t is closed and well defined (t : T for some T) then either t is a value of for some t’: t t’
• Permutation: if t : T and is a permutation of then t : T
• Weakening: if t : T and x dom() then , x : S t : T• Preservation of types under substitution:
– If , x : S t : T and s : S then [x s] t : T
• Preservation: if t : T and t t’ then t’ : T
Implicit vs. Explicit Types
• Do we have to spell out the type of every argument?
• Implicit type systems allow the programmers to omit the types as long as the resulting type is unique– Reduces the annotation burden
• A type inference algorithm infers a unique type or issues an error
Other Issues
• The Curry-Howard Correspondence
• Erasure of typability
• Curry-Stlyle vs. Church style of languages definition
Extensions
• Subtyping (Chapters 15-19)– Most general type
• Recursive Types (Chapters 20, 21)– NatList = <Nil: Unit, cons: {Nat, NatList}>
• Polymorphism (Chapters 22-28)– length:list int– Append: list list
• Higher-order systems (Chapters 29-32)