1 / 82

CS5205: Foundation in Programming Languages Lecture 7 : Extended Type System

CS5205: Foundation in Programming Languages Lecture 7 : Extended Type System. Base & Unit Types Sequencing Ascription Let bindings Pairs, Tuples, Records Sums, variants Recursion References Exceptions. Pure Simply Typed Lambda Calculus. t ::= terms x variable

trudy
Download Presentation

CS5205: Foundation in Programming Languages Lecture 7 : Extended Type System

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. CS5205: Foundation in Programming LanguagesLecture 7 :Extended Type System • Base & Unit Types • Sequencing • Ascription • Let bindings • Pairs, Tuples, Records • Sums, variants • Recursion • References • Exceptions Extended Type System

  2. Pure Simply Typed Lambda Calculus • t ::= terms • x variable • l x:T.t abstraction • t t application • v ::= value • l x :T.t abstraction value • T ::= types • T ! T type of functions • G ::= contexts •  empty context • G, x:T type variable binding Extended Type System

  3. Call-by-Value Semantics (E-App1) (E-App2) (l x.t) v ! [x a v] t(E-AppAbs) Extended Type System

  4. Typing (T-Var) (T-Abs) (T-App) Extended Type System

  5. Where are the Base Types? • T ::= types • T ! T type of functions • Extend with uninterpreted base types, e.g. • T ::= types • T ! T type of functions • A base type 1 • B base type 2 • C base type 3 • : Extended Type System

  6. Examples lx:A. x lf:A! B. lx:A. f(x) lf:A! A. lx:A. f(x) lf:B! B. lx:B. f(f(x)) Base types are Bool, Nat, etc. The above types are monomorphic rather than polymorphic. For polymorphic types, we need to use type variables, denoted by say , , etc. Extended Type System

  7. Unit Type • New Syntax: • t ::= … terms • unit constant unit • v ::= … values • unit constant unit • T ::= … types • Unit unit type • Note that Unit type has only one possible value. • New Evaluation Rules: None • New Typing Rules : • ` unit : Unit T-Unit Extended Type System

  8. Sequencing : Basic Idea Syntax : e1; e2 Evaluate an expression (to achieve some side-effect, such as printing), ignore its result and then evaluate another expression. Examples: (print x); x+1 (printcurrenttime); compute; (printcurrenttime) Extended Type System

  9. New Evaluation Rules: t1! t‘1 (E-Seq) t1 ; t2! t‘1 ; t2 unit ; t ! t(E-SeqUnit) Lambda Calculus with Sequencing • New Syntax • t ::= … terms • t ; t sequence Extended Type System

  10. Sequencing (cont) New Typing Rule: (T-Seq) Extended Type System

  11. Sequencing (Second Version) • Treat t1;t2 as an abbreviation for (lx:Unit. t2) t1. • Then the evaluation and typing rules for abstraction and application will take care of sequencing! • Such shortcuts are called derived forms (or syntactic sugar) and are heavily used in programming language definition. Extended Type System

  12. Equivalence of Sequencing Extension • Let lE be the simply typed lambda calculus with the Unit type and the sequencing construct. • Let lI be the simply-typed lambda calculus with Unit only. • Let e 2 lE!lI be the elaboration function that translates from lE To lI. • Then, we have for each term t: • t !E t’ iff e(t) !I e(t’) • `E t:T iff`I e(t):T Extended Type System

  13. Ascription : Motivation • Sometimes, we want to say explicitly that a term has a certain type. • Reasons: • as comments for online documentation • for debugging type errors • control printing of types (together with type syntax) • casting (as in Java) • resolve ambiguity (of more complex typing) Extended Type System

  14. Ascription : Syntax • New Syntax • t ::= … terms • t as T ascription Example: (f (g (h x y z))) as Bool Extended Type System

  15. Ascription (cont) New Evaluation Rules: v as T ! v(E-Ascribe1) (E- Ascribe2) New Typing Rules: (T-Ascribe) Extended Type System

  16. Let Bindings : Motivation • Let expression allow us to give a name to the result of an expression for later use and reuse. • Examples: • let pi=<long computation> in …pi..pi..pi…. • let square = l x:Nat. x*x in ….(square 2)..(square 4)… Extended Type System

  17. Lambda Calculus with Let Binding • New Syntax • t ::= … terms • let x=t in t let binding New Evaluation Rules let x=v in t2! [x a v] t2 (E-Let1) (E- Let2) Extended Type System

  18. Let Binding (cont) New Typing Rule: (T-Let) Extended Type System

  19. Let Bindings as Derived Form We can consider let expressions as derived form: In untyped setting: let x=t1 in t2 abbreviates to (l x. t2) t1 In a typed setting: let x=t1 in t2 abbreviates to (l x:?. t2) t1 How to get type declaration for the formal parameter? Answer : Type inference (see next lecture). Extended Type System

  20. Pairs : Motivation • Pairs provide the simplest kind of data structures. • Examples: • (9, 81) • l x : Nat. (x, x*x) Extended Type System

  21. Pairs : Syntax • t ::= … terms • (t, t) variable • t.1 first projection • t.2 second projection • v ::= … value • (v, v) pair value • T ::= … types • T £ T product type Extended Type System

  22. Pairs : Evaluation Rules (E-PairBeta1) (v1, v2).1 ! v1 (E-PairBeta2) (v1, v2).2 ! v2 (E-Proj1) (E-Proj2) Extended Type System

  23. Pairs : Evaluation Rules (cont) (E-Pair1) (E-Pair2) Extended Type System

  24. Pairs : Typing Rules (T-Pair) (T-Proj1) (T-Proj2) Extended Type System

  25. Tuples Tuples are a straightforward generalization of pairs, where n terms are combined in a tuple expression. Example: (1, true, unit) : (Nat, Bool, Unit) (1,(true, 0)) : (Nat, (Bool, Nat)) ( ) : ( ) Note that n may be 0. Then the only value is ( ) with type ( ). Such a type is isomorphic to Unit. Extended Type System

  26. Records Sometimes it is better to have components labeled more meaningfully instead of via numbers 1..n, as in tuples Tuples with labels are called records. Example: {partno=5524, cost=30.27, instock =false} has type {partno:Nat, cost:Float, instock:Bool} instead of: (5524,30.27,false) : (Nat, Float, Bool) Extended Type System

  27. Tuples as Records We can treat tuples as an abbreviation for records whose fields are numbers from 1 to n. Example: (1, true, unit) is abbreviation for {1=1, 2=true, 3=unit} Extended Type System

  28. Pattern-Matching : Motivation It is often convenient to access some or all components of a record simultaneously as in: let {partno=p, cost=c, instock=i} = accessdb key1 key2 in …p…c…i… let construct can be extended with pattern-matching. Usually case construct also used for sum/variant type to be described next. Extended Type System

  29. Pattern-Matching • New syntactic Form: • p ::= x variable pattern • {li=pi}i 2 1..n record pattern • t ::= … terms • let p=t in t pattern binding Extended Type System

  30. Pattern-Matching (cont) Matching Rules : match(x,v) = [x a v] (M-Var) (M-Rcd) Evaluation Rules : (E-LetV) let p=v in t !match(p,v) t (E-Let) Extended Type System

  31. Sums : Motivation • Often, like to handle values of different structures with the same function. • Examples: • PhysicalAddr={firstlast:String, add:String} • VirtualAddr={name:String, email:String} • A sum type can then be written like this: • Addr = PhysicalAddr + VirtualAddr Extended Type System

  32. Sums : Motivation • Given a sum type; e.g. • K = Nat + Bool • Need to use tags inl and inr to indicate that a value is a particular member of the sum type; e.g. • inl 5 : K but not inr 5 : K nor 5 : K • inr true : K Extended Type System

  33. Sums : Motivation • Given the address type: • Addr = PhysicalAddr + VirtualAddr • We can use case construct to analyse the particular value of sum type: • getName = l a : Addr. case a of • inl x => a.firstlast • inr y => y.name Extended Type System

  34. Problem : Uniqueness of Types • Given the address type: • PhysicalAddr={firstlast:String, add:String} • VirtualAddr={name:String, email:String} • PagingUser={name:String, pager:String} • Addr = PhysicalAddr + VirtualAddr • UserCoord = PagerUser + VirtualAddr • What is the type of : • inr {name : “chin”, email=“chinwn@comp.nus.edu.sg”} ? Extended Type System

  35. Resolving Ambiguous Types • Analyse the program to find out what type should be. (Type inference) • Given a type that includes all possible sum types. (Subtyping) • Force programmer to explicitly declare the type using ascription. Extended Type System

  36. Sums : Syntax • t ::= … terms • inl t as T tagging (left) • inr t as T tagging (right) • case t of {pi => ti} pattern matching • v ::= … value • inl v as T tagged value (left) • inr v as T tagged value (right) • T ::= … types • T + T sum type Extended Type System

  37. Sums : Evaluation Rules (E-Case) case (inl v as T) of {inl x1) t1 | inr x2) t2} ! [x1a v] t1 (E-CaseInl) case (inr v as T) of {inl x1) t1 | inr x2) t2} ! [x2a v] t2 (E-CaseInr) Extended Type System

  38. Sums : Evaluation Rules (E-Inl) (E-Inr) Extended Type System

  39. Sums : Typing Rules (T-Inl) (T-Inr) Extended Type System

  40. Variants : Labeled Sums Instead of inl and inr, we may like to use nicer labels, just as in records. This is what variants do. For types, instead of: T1 + T2 we write: <l1:T1 + l2:T2> For terms, instead of: inl r as T1 + T2 we write: <l1= t> as <l1:T1 + l2:T2> Extended Type System

  41. Variants : Example • An example using variant type: • Addr =<physical : PhysicalAddr, virtual : VirtualAddr> • A variant value: • a = <physical=pa> as Addr • Function over variant value: • getName = l a : Addr. • case a of • <physical=x> ) x.firstlast • <virtual=y> ) y.name Extended Type System

  42. Application : Options • Option type denotes a maybe value: • OptionNat =<none : Unit, some : Nat> • Table = Nat ! OptionNat • Operations on Table: • emptyTable = l n : Nat. <none=unit> as OptionNat • extendTable = • l t:Table. l m:Nat l v: Nat. • l n:Nat. • if equal n m then <some=v> as OptionNat • else t n Extended Type System

  43. Application : Enumeration • Enumeration are variants that only make use of their labels. Each possible value is unit. • Weekday =<monday:Unit, tuesday:Unit, • wednesday:Unit, thursday:Unit, friday:Unit > Extended Type System

  44. Application : Single-Field Variants • Labels can be convenient to add more information on how the value is used. • Example, currency denominations (or units): • DollarAmount =<dollars:Float> • EuroAmount =<euros:Float> Extended Type System

  45. Recursion : Motivation • Recall the fix-point combinator: • fix = l f. (l x. f (l y. x x y)) (l x. f (l y. x x y)) • Unfortunately, it is not valid (well-typed) in simply typed lambda calculus. • Solution : provide this as a language primitive that is hardwired. Extended Type System

  46. Recursion : Syntax & Evaluation Rules • New Syntax • t ::= … terms • fix t fixed point operator • New Evaluation fix (l x : T. t) ! [x a fix (l x : T. t)] t (E-FixBeta) (E-Fix) Extended Type System

  47. Recursion : Typing Rules (T-Fix) Can you guess the inherent type of fix? Extended Type System

  48. References : Motivation Many languages do not syntactically distinguish between references (pointers) from their values. In C, we write: x = x+1 For typing, it is useful to make this distinction explicit; since operationally pointers and values are different. Extended Type System

  49. References : Motivation Introduce the syntax (ref t), which returns a reference to the result of evaluating t. The type of ref t is Ref T, if T is the type of t. Remember that we have many type constructors already: Nat £ float {partno:Nat,cost:float} Unit+Nat <none:Unit,some:Nat> Extended Type System

  50. Typing : First Attempt (T-Ref) (T-Deref) (T-Assign) Extended Type System

More Related