1 / 32

Type Systems

- Vasvi Kakkad. Type Systems. What is Type System?. 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. Why? - Motivations.

christen-alvarado
Download Presentation

Type Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. - Vasvi Kakkad Type Systems

  2. What is Type System? • 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. Why? - Motivations • Space management & runtime efficiency • Improved program correctness • ADT and modularity support • Building language semantic model

  4. Definition • 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. Types and Type Systems • Notes on the definition: • Static checking implied: the goal is to proveabsence of certain errors. • Classificationof 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. Types & Type system • 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. Types & Type system • “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. Types & Type system • 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. Types & Type system • 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 • 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 • 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)

  12. Language Safety

  13. Static & Dynamic Semantics • 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: Abstract Syntax • Example language t → terms: true constant true | false constant false | if t then t else t conditional | 0constant zero | succ t successor | pred t predecessor | iszero t zero test

  15. Values • The valuesof 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. Values v → values: true true value | false false value | nv numeric value nv → numeric values: 0zero value | succ nv successor value

  17. Operational Semantics • t → t′ is an evaluation relation on termst 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. Operational Semantics 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. Operational Semantics iszero 0 true (E-ISZEROZERO) iszero(succ nv1)  false (E-ISZEROSUCC) t1  t1’ (E-ISZERO) iszero(t1)iszero(t1’)

  20. Operational Semantics • Note that: • Valuescannot 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. Stuckness and Run-Time Errors • 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. Types • 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. Typing Rules 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. Safety = Progress + Preservation • 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. Safety = Progress + Preservation • 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. Progress: A Proof Fragment • 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. Progress: A Proof Fragment • 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. Exceptions • 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. Exceptions • Idea: allow exceptions to be raised, and make itwell-defined what happens when exceptions are raised. • For example: • introduce a term error • introduce evaluation rules like head []→ error

  30. Exceptions • 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. Summary • 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

  32. Thank You...

More Related