1 / 40

Type Systems

Type Systems. Doaitse Swierstra Atze Dijkstra. Components. lectures from the book “Types and Programming Languages” , Benjamin Pierce study the type inferencer/checker of the Utrecht Haskell Compiler (UHC) project small exercises. Prerequisites. Grammars and Parsing

ziv
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. Type Systems • Doaitse Swierstra • Atze Dijkstra

  2. Components • lectures from the book “Types and Programming Languages”, Benjamin Pierce • study the type inferencer/checker of the Utrecht Haskell Compiler (UHC) • project • small exercises

  3. Prerequisites • Grammars and Parsing • Implementation of Programming Languages • fluency in Haskell programming

  4. Book • should be relatively easy to follow, but it will take time (500 pages) • well written, with extensive set of exercises • both theory and practice • uses ML as a demonstration and implementation language • written at an easy pace

  5. UHC • “extension” of IPT compiler • data types • multiparameter type classes • forall and existential quantifiers • polymorphic kinds

  6. Projects • Modules • Extendible Records • Functional Dependencies • Typed AG • XMLambda • Unifying Kind and Type Inference • Kind Inferencing in Helium • Haskell Type System • Uniqueness Types • Implicit Arguments

  7. 1 Modules • import and export types • keep safety • class issues • parallel imports • typed annotations • ML functors

  8. 2 Extendible Records • allow cartesian products with labelled fields • subtype relation • use class sytem to express constraints • many different proposals exits

  9. 3 Functional Dep’cies • allow parameters in instance definitions to have a functional relationship • very useful in multi-parameter type classes • implemented in Hugs and GHC

  10. Typed AG • add elements of Haskell to AG system • delicate choice of features has to be made • useful work, as you will all recognise

  11. XMLambda • yet another approach to extendible records • moves further away from Haskell • has nice applications

  12. Unifying Type and Kind Inference • type inference and kind inference are very similar • make the code look just as similar • can this be extended to even more levels?

  13. Kind Inference in Helium • Helium: light weight Haskell for first year students • excellent error messages • tranport kind inference to helium • contraint based type inferencer

  14. Haskell Type System • study the full haskell type system • document missing features from UHC • add some of the still missing elements

  15. Uniqueness Types • the type system keep tracks of the number of references to a value (1 or >1) • replacement for IO monad • invented and implemented in Clean • makes efficient implementation possible • avoids dynamic garbage collection

  16. Implicit Arguments • generalise the class parameters • extend haskell so you can make classes into first class citizens

  17. What to do now? • if you want a specific partner then choose a partner • decide on your preferences ranking 1-5 for your top 5 preferred projects • mail to doaitse@cs.uu.nl before tomorrow 17.00

  18. Chapter 1-10 • motivation • mathematical preliminaries • untyped arithmetic expressions • the untyped lambda calculus • nameless representation of terms

  19. 1-10 continued • ML implementation • Typed arithmetic expressions • Simply typed lanbda calculus • ML implementation

  20. Observations • nothing in these chapters should come as a surpsise • and you should just browse/read • ML is used: • somewhat baroque notation!! • strict evaluation!! • the theory treated at some points relies on this!, so keep this in mind

  21. Why types? • originally: data organistation, layout of data in memory: PIC (99) • overloading, nice notation: 3+5.0 • programs should not go wrong • elementary operations are applied to bit patterns that represent the kind of data they expect • programs do terminate

  22. Why Types? • assist in organisation of program code • dependent types => total correctness • a type system constrains the number of legal programs is some useful way

  23. Kind of Typing Systems • dynamic typing (LISP, Java coercions) • static typing (as you know it) • Higher Order Logic, Automath • integration with theorem provers • the type system can express every property of a program

  24. Our preference here Proving program properties • operational semantics • big step semantics • small step semantics • denotational semantics • axiomatic semantics

  25. Lambda calculus • we can express every possible computation in the untyped lambda calculus

  26. t ::= true | false | if t then t else t v ::= true | false if true then t1 else t2 => t1 if false then t1 else t2 => t2 Booleans

  27. t1 -> t1’ if t1 then t2 else t3 => if t1’ then t2 else t3 Booleans (strict evaluation) • note that the condition is evaluated before the expressions themselves are

  28. Observe • evaluation is deterministic (i.e. always exactly one rule applies) • evaluation always terminates • normal forms are unique

  29. t ::= 0 | succ t | pred t | iszero t nv :: = 0 | succ nv t1 => t2 succ t1 => succ t2 Arithmetic Expressions

  30. Booleans tru = \t.\f.t fls = \t.\f.f if = \c.\t.\e. c t e if tru 2 3 => (\c.\t.\e. c t e) tru 2 3 => ( \t.\e. tru t e) 2 3 => ( \e. tru 2 e) 3 => tru 2 3 => (\t.\f.t) 2 3 => ( \f.2) 3 => ( 2)

  31. Integers c0 = \s.\z. z c1 = \s.\z. s z c2 = \s.\z.s (s z) c3 = \s.\z.s (s (s z))

  32. Recursion!! omega = (\x. x x)(\x. x x) ?? fix = \f.(\x. f(x x)) (\x. f(x x)) fix g => (\x. g(x x))(\x. g(x x)) => g((\x. g(x x))(\x. g(x x))) => g (fix g)

  33. Recursion (cont.) • note that fix generates copies of g if necessary • and passes the generater on to this g • so that g can generate new copies is necessary

  34. Exercise • try to find a type for fix • if you cannot find one, try to explain why you cannot

  35. v :: = \x.t t ::= x | \x.t | t t Untyped lambda calculus

  36. De Bruijn Indices • represent lambda terms without using identifiers • an identifier is replaced by a number indicating how far the argument is removed from the top of the stack

  37. Example is represented by

  38. Terms

  39. Exercise • define a Haskell data type for the untyped lambda calculus with variables • define a Haskell data type for representing de Bruijn terms • define a translation from the first to the second • write a small interpreter for the latter

  40. Hint • Chapter 6: de Bruijn numbers • Chapter 7: an interpreter in ML

More Related