Types and Programming Languages

Robert Harper

In Honor of Dana S. Scott

October, 2002

ScottFest 2002 2

Constructive Validity (1968)

• A semantics for intuitionistic logic.– 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: ` t : , where

– provides types for variables;– 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 ` iff t1:1,…,tn:n ` t : for some construction t;

• Conjecture: decidable whether ; ` 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 pure functional 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: ::¾ , ie, ((¾?)¾?)¾.– Equivalently, EM: :Ç .

• What program has this type?– Griffin, Felleisen: callcc!– callcc : ((! void)! void) !

• 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 Ç: works as follows:– Expects two “handlers”, one for , one for :, each

yielding a result of the same type.– The proof tEM calls the : handler, passing it a

well-chosen “proof” t of ¾?.– The handler for : might apply t to a proof of ,

obtaining a contradiction; : 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.– ! becomes ! (! ans) ! ans), which is a

lot like ! ::.

• 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 x.k.e(k)(k),

of type ! ((! 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 . : generics (.t), instances (t[]).– 9 . : 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 24

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 25

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 26

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 27

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 28

Modularity

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

ScottFest 2002 29

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 30

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 31

Sub-structural Systems

• Weakening:

• Contraction:

• Permutation:

ScottFest 2002 32

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 33

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 34

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 35

Sub-structural Systems

• Strict type systems distinguish by-value from by-name function spaces.– !: may or may not use argument, may use

many times. Evaluate by-name.– !s : 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 36

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 iff = 1,x:,y:,2.

ScottFest 2002 37

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 38

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 39

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 40

Thanks, Dana!