Presentation on theme: "- Vasvi Kakkad. Formal - Tool for mathematical analysis of language Method for precisely designing language Well formed model for describing and."— Presentation transcript:
Formal - Tool for mathematical analysis of language Method for precisely designing language Well formed model for describing and analysing language semantics Bridges a language syntax and semantic model
Space management & runtime efficiency Improved program correctness ADT and modularity support Building language semantic model
A plausible definition: “A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.”
Notes on the definition: Static checking implied: the goal is to prove absence of certain errors. Classification of syntactic phrases (or terms) according to the kinds of value they compute - a type system computes a static approximation of the run-time behavior.
Example: if known that two program fragments exp1 and exp2 compute integers (classification), then we know that it is safe to add those numbers together (absence of errors): exp1 + exp2 We also know that the result is an integer. Thus we know that all involved entities are integers. (static approximation).
“Dynamically typed” languages do not have a type system according to this definition - dynamically checked. Example: Before evaluating exp1 + exp2, it has to be checked that both exp1 and exp2 actually evaluated to integers
A type system is necessarily conservative Some programs that actually behave well will be rejected. Example: if complex test then S else type error Rejected as ill-typed, even if complex test actually always evaluates to true
A type system checks for certain kinds of program behavior run-time errors. Example: main-stream type systems do check - arithmetic operations are done only on numbers do not check - the second operand of division is not zero
Language safety is a contentious notion. A possible definition : A safe language is one that protects its own abstractions. For example: an array should behave as an array; Other examples: lexical scope rules, visibility attributes(public, protected,... ).
Language safety is not same as static type safety Scheme - dynamically checked safe language. Even languages with static type checking usually use some dynamic checks: checking of array bounds down-casting (e.g. Java)
A type system is a way to statically prove properties about the dynamic behavior of a program expressed in some language. This is the “Curry-style” approach: The dynamic semantics comes before the static semantics. Alternative - the “Church-style” approach.
Example language t → terms: true constant true | false constant false | if t then t else t conditional | 0 constant zero | succ t successor | pred t predecessor | iszero t zero test
The values of a language are a subset of the terms that are possible results of evaluation. The evaluation rules are going to be such that no evaluation is possible for values. normal form All values are normal forms.
v → values: true true value | false false value | nv numeric value nv → numeric values: 0 zero value | succ nv successor value
t → t ′ is an evaluation relation on terms t evaluates to t ′ in one step. Operational semantics for the example language. if true thent2 else t3 → t2 (E-IFTRUE) if false thent2 else t3 → t3 (E-IFFALSE) t1 → t ′ 1 (E-IF) if t1 then t2 else t3 → if t ′ 1 then t2 else t3
t1 t1’(E-Succ) succ t1 succ t1’ pred 0 0 (E-PREDZERO) pred(succ(nv1) nv1(E-PREDSUCC) t1 t1’(E-PRED) pred t1 pred t1’
Note that: Values cannot be evaluated further. E.g.: - true - 0 Certain “obviously nonsensical” states are stuck: the term cannot be evaluated further, but it is not a value. For example: if 0 then pred 0 else 0
We let the notion of getting stuck model run- time errors. The goal of a type system is thus to guarantee that a program never gets stuck!
At this point, there are only two types, booleans and the natural numbers: T → types: Bool type of Booleans | Nat type of natural numbers
The most basic property of a type system safety “well typed programs do not go wrong”, where “wrong” means entering a “stuck state”. Progress: A well-typed term is not stuck. Preservation: If a well-typed term takes a step of evaluation, then the resulting term is also well-typed
THEOREM [PROGRESS]: Suppose that t is a well-typed term (i.e., t : T), then either t is a value or else there is some t ′ with t → t ′. THEOREM [PRESERVATION]: If t : T and t → t ′ then t ′ : T.
The relevant typing and evaluation rules for the case T-IF: t1:Bool t2:T t3:T(T-IF) if t1 then t2 else t3:T if true then t2 else t3 → t2 (E-IFTRUE) if false then t2 else t3 → t3 (E-IFFALSE) t1 → t ′ 1 (E-IF) if t1 then t2 else t3 → if t ′ 1 then t2 else t3
A typical case when proving Progress by induction on a derivation of t : T Case T-IF: t = if t1 then t2 else t3 t1 : Bool t2 : T t3 : T If t1 is a value, then - true or false, either E-IFTRUE or E-IFFALSE applies to t if t1 → t ′ 1, then by E-IF, t → if t ′ 1 then t2 else t3.
What about terms like division by zero head of empty list If the type system does not rule them out, we need to differentiate those from stuck terms, or we can no longer claim that “well-typed programs do not go wrong”!
Idea: allow exceptions to be raised, and make it well-defined what happens when exceptions are raised. For example: introduce a term error introduce evaluation rules like head  → error
Introduce further rules to ensure that the entire program evaluates to error once the exception has been raised Change the Progress theorem slightly to allow for exceptions. (Aside: For technical reasons, it is good to not consider error a value. Hence the need to tweak the progress theorem.)
Type System – Statically proves dynamic behaviour of program Static checking and dynamic checking Language safety proven by – Type system Safety = progress + preservation Handle exceptions with type systems