1. - Vasvi Kakkad

2.  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

3.  Space management & runtime efficiency  Improved program correctness  ADT and modularity support  Building language semantic model

4.  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.”

5.  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.

6.  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).

7.  “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

8.  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

9.  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

10.  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,... ).

11.  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)

13.  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.

14.  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

15.  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.

16. v → values: true true value | false false value | nv numeric value nv → numeric values: 0 zero value | succ nv successor value

17.  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

18. 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’

19. iszero 0  true(E-ISZEROZERO) iszero(succ nv1)  false (E-ISZEROSUCC) t1  t1’(E-ISZERO) iszero(t1)  iszero(t1’)

20.  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

21.  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!

22.  At this point, there are only two types, booleans and the natural numbers: T → types: Bool type of Booleans | Nat type of natural numbers

23. true : Bool(T-TRUE) false : Bool(T-FALSE) t1:Bool t2:T t3:T(T-IF) if t1 then t2 else t3:T 0 : Nat(T-ZERO) t1:Nat(T-SUCC) succ(t1) : Nat t1:Nat(T-ISZERO) iszero(t1) : Bool

24.  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

25.  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.

26.  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

27.  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.

28.  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”!

29.  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

30.  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.)

31.  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