1 / 39

Types and Programming Languages

Types and Programming Languages. Robert Harper In Honor of Dana S. Scott October, 2002. Constructive Validity (1968). A semantics for intuitionistic logic . Proofs are (functional) programs. Propositions are types of constructions. Formalization of the Heyting semantics .

adsila
Download Presentation

Types and Programming Languages

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. Types and Programming Languages Robert Harper In Honor of Dana S. Scott October, 2002

  2. Constructive Validity (1968) • A semantics for intuitionisticlogic. • Proofs are (functional) programs. • Propositions are types of constructions. • Formalization of the Heyting semantics. • First-order, but not second- or higher-order, quantification. • Domains include naturals and well-founded trees (but not choice sequences). ScottFest 2002

  3. Constructive Validity (1968) • Anticipated and inspired a large body of work on constructive semantics. • Martin-Löf’s type theories. • Calculus of Constructions. • NuPRL. • Profound influence on theoretical CS. • Initiated the use of type theory as a theoretical framework for programming languages. ScottFest 2002

  4. Constructivism • Mathematics consists of carrying out constructions. • Of mathematical objects such as geometric figures, numbers, functions, …. • Of proofs of propositions, so that logic is part of mathematics, rather than vice versa. ScottFest 2002

  5. Constructions and Types • CV is a theory of constructions. • Effectively performable by an idealized mathematician (one without time or space limitations). • Constructions are classified by types. • Values, or introduction forms. • Operations, or elimination forms. ScottFest 2002

  6. Constructions and Types • Propositional constructions: • 0 (?) : (empty), empty function • 1 (>) : ¤, trivial function • 1£2 (1Æ2): pairing, projection. • 1+2 (1Ç2): injection, case analysis • 1!2 (1¾2): abstraction, application ScottFest 2002

  7. Constructions and Types • Quantification domains: • N: naturals, primitive recursion. • W : well-founded trees, tree induction. • Predicate constructions: • t1 = t2 : reflexivity, presumed equality •  x:. (8 x:.): gen’lization, instantiation •  x:. (9 x:.): exemplification, choice ScottFest 2002

  8. Typing Constructions • Typing judgement: G`D t : t, where • D provides types for variables; • G records proof assumptions. • Assumptions in CV may have the force of equations! • CV is an “extensional” type theory. • Others stressed “intensional” variants. ScottFest 2002

  9. Constructive Validity • Constructive validity of entailment:1,…,n`D  iff t1:1,…,tn:n`D t :  for some construction t; • Conjecture: decidable whether ;`D t : . • Not true under hypotheses because of extensional equality. • Has this ever been proved? ScottFest 2002

  10. Types for Programs • Scott’s CV stresses types inspired by logic. • One type constructor for each form of proposition. • Plus types for the domains of quantification. • Constructions are purefunctional programs. • Total functions of finite order. • Number and tree recursion. • Simple data structures (tuples, variants, finite sets, naturals, well-founded trees). ScottFest 2002

  11. Types for Programs • Computer scientists stress programs. • Primary object of study (naturally!). • Types ensure good properties such as type safety, representation independence, invariants. • Scott’s CV suggests the use of types to codify design patterns. • Programming constructs are organized by type. • Programming languages are collections of types. ScottFest 2002

  12. Types for Programs • How far can we push this idea? • Find logical type systems corresponding to new and known design patterns. • Logical type theory is the GUT of PL’s! • Higher-order logics for generics and abstraction. • Classical logic for non-local control. • Modal logics for meta-programming, effects (see Pfenning’s talk). • Sub-structural (linear, ordered, affine) logics for state change, data layout. ScottFest 2002

  13. Classical Validity • The usual semantics of classical logic is non-effective. • Boolean algebras, esp. truth tables. • No apparent constructive content. • Yet the Gödel translation constructivizes it! • There is some effective content in the proof. • eg, Friedman’s A-translation shows coincidence for 89 sentences of arithmetic. ScottFest 2002

  14. Control Operators • CL = IL + DNE • DNE: ::f ¾ f, ie, ((f¾?)¾?)¾f. • Equivalently, EM: :f Ç f. • What program has this type? • Griffin, Felleisen: callcc! • callcc : ((t! void)! void) !t • Callcc is a control operator. • Used for exceptions, co-routines, threads. • Essentially a “functional jump”. ScottFest 2002

  15. Control Operators • Example (in SML):fun ml (l : int list):int = callcc( fn ret => let fun loop nil = 1 | loop 0::t => throw ret 0 | loop h::t => h*loop t in loop l end ) ScottFest 2002

  16. Control Operators • Callcc allows re-running of code. • Capture a control point. • Return to that point by throwing it a value. • In particular a function can return more than once. • We may use callcc to give constructive content to EM! ScottFest 2002

  17. Control Operators • Idea: the proof tEM of fÇ:f works as follows: • Expects two “handlers”, one for f, one for :f, each yielding a result of the same type. • The proof tEM calls the :f handler, passing it a well-chosen “proof” t of f¾?. • The handler for :f might apply t to a proof of f, obtaining a contradiction; :f must have been the wrong choice! • The function t retracts the previous choice, passing control instead to the  handler with the given proof of ! ScottFest 2002

  18. CPS Transform • A standard implementation of callcc is the CPS transform. • Pass the “return address” explicitly as a continuation. • s!t becomes s! (t! ans) ! ans), which is a lot like s!::t. • The initial continuation extracts the ultimate answer of the computation. ScottFest 2002

  19. CPS Transform • For example, we may rewrite ml using continuations as follows:fun mlcps(l, k) = let fun loop nil = 1 | loop 0::t = k 1 | loop h::t = h * loop t in loop l end ScottFest 2002

  20. CPS Transform • The CPS transform eliminates callcc! • callcc(e) becomes lx.lk.e(k)(k), of type s! ((t! ans)! ans). • Duplicates the return address for the “normal” and the “repeated” return. • Consequences: • Classical logic is constructive. • Types for control operators are classical. ScottFest 2002

  21. Second-Order Logic • Second-order types / propositions: • 8.f : generics (L.t), instances (t[f]). • 9.f : packages, data abstraction. • Two independent discoveries: • Reynolds: polymorphism in programming. • Girard: proof theory of higher-order arithmetic. ScottFest 2002

  22. Second-Order Logic • Universals: • Existentials: 8. = 8.(8.¾)¾. ScottFest 2002

  23. Program Modules • Second-order propositional type theory determines an indexed category P: • Base: type constructors  : ). • Fibres: proofs/programs t : ! over . • Quantifiers are adjoints to projection. • A fibred view provides types for higher-order program modules! • The “total category”  P of P. • Package  with terms over . ScottFest 2002

  24. Program Modules • Skeletally, a module consists of: • A static part, defining some types. • A dynamic part, defining some code. • The signature of a module is its type. signature PREORD =sig type t val lt : t * t -> boolend ScottFest 2002

  25. Program Modules • A module implements a signature:structure IntLT : PREORD = struct type t = int val lt = (< : int * int -> bool)end • Signatures are closed under function spaces.signature PF =PREORD ! PREORD ScottFest 2002

  26. Program Modules • But what kind of functions? • The static part of the result is computed only in terms of the static part of the argument. • The dynamic part of the result is computed in terms of both the static and dynamic part of the argument. • That is, module equivalence is coarser than would ordinarily be the case. ScottFest 2002

  27. Modularity • Idea: phase-separation interpretation of functions over modules.PREORD ! PREORD ´sig con t :  )  val f : 8a (a * a! bool) ! (t(a) * t(a)) ! boolend ScottFest 2002

  28. Modularity • Theorem: The induced module type theory admits higher-order functions validating phase separation equations. • Follows directly from working out the Grothendieck construction in the language of type theory. • Basis for implementation of SML modules in the TILT compiler. ScottFest 2002

  29. Sub-structural Systems • Structural rules govern the use of variables in programs / proofs. • Contraction: duplication of variables. • Weakening: dropping a variable. • Permutation: re-ordering variables. • Intuitionistic type theory validates all three of these structural rules. ScottFest 2002

  30. Sub-structural Systems • Weakening: • Contraction: • Permutation: ScottFest 2002

  31. Sub-structural Systems • Sub-structural type systems limit these. • Linear: : C, : W, P (“exactly one”) • Affine: : C, W, P (“zero or one”) • Strict: : W, P (“one or more”) • Ordered: : C, : W, : P (“adjacency”) • Type constructors proliferate! • Enable fine distinctions lost in ITT. • Surprisingly powerful for programming. ScottFest 2002

  32. Sub-structural Systems • Contraction requires garbage collection. • Many variables may “alias” the same data structure. • There is no “local” test for whether storage can be freed. • The collector performs a global scan to find all references. • All familiar languages admit contraction. ScottFest 2002

  33. Sub-structural Systems • Linear type systems avoid garbage collection, but require explicit de-allocation. • No aliasing: exactly one reference to any object. • Reclamation: using an object frees its storage. • Unused objects must be explicitly freed. • Affine type systems have implicit reclamation. • Dropping a variable is allowed, by weakening. • Using weakening frees storage. ScottFest 2002

  34. Sub-structural Systems • Strict type systems distinguish by-value from by-name function spaces. • s!t: may or may not use argument, may use many times. Evaluate by-name. • s!st: may use argument one or more times. Evaluate by-value. • These may co-exist in one language! • Use Pfenning’s “zones” to segregate restricted from unrestricted variables. • (Conventional practice notwithstanding.) ScottFest 2002

  35. Sub-structural Systems • Ordered type systems capture low-level data representations. • Required for inter-operability with foreign code. • For example, tuples must be laid out in a specified order. • Denial of permutation permits consideration of adjacency (contiguity) of data values. • x is to the left of y in D iff D = D1,x:s,y:t,D2. ScottFest 2002

  36. Sub-structural Systems • Permutation precludes commitment to representations. • Tuples may be laid out in any order in memory. • Projections determine the “logical” order. • Ordering supports an adjacent product, or fuse, connective. •  ² : ordered pair with v: to the left of w:. • Especially useful in compiler intermediate languages! • Eg, to satisfy external layout constraints. ScottFest 2002

  37. Other Directions • Modalities (see Pfenning’s talk). • Computational effects. • Meta-programming. • Mobility. • Dependencies. • Most PL work is based on type systems for propositional logics. • Type theories based on predicate logics are the subject of active research. ScottFest 2002

  38. Summary • Scott’s CV initiated the type-theoretic study of programming languages. • Types codify programming patterns. • Type systems correspond to logical systems (and to categorical structure). • The implications of these ideas are still being understood! ScottFest 2002

  39. Thanks, Dana! ScottFest 2002

More Related