Types and Programming Languages

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