Types and Programming Languages Robert Harper In Honor of Dana S. Scott October, 2002

Download Report

Transcript Types and Programming Languages Robert Harper In Honor of Dana S. Scott October, 2002

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.
– First-order, but not second- or higher-order,
quantification.
– Domains include naturals and well-founded
trees (but not choice sequences).
ScottFest 2002
2
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
3
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
4
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
5
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
6
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
7
Typing Constructions
• Typing judgement: G `D 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
8
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
9
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
10
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
11
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
12
Classical Validity
• The usual semantics of classical logic is noneffective.
– 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
13
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
14
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
15
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
16
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
17
CPS Transform
• A standard implementation of callcc is
the CPS transform.
– Pass the “return address” explicitly as a
continuation.
– s! becomes s ! (! ans) ! ans), which is a
lot like s ! ::.
• The initial continuation extracts the
ultimate answer of the computation.
ScottFest 2002
18
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
19
CPS Transform
• The CPS transform eliminates callcc!
– callcc(e) becomes lx.lk.e(k)(k),
of type s! ((! 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
20
Second-Order Logic
• Second-order types / propositions:
– 8 . : generics (L.t), instances (t[]).
– 9 . : packages, data abstraction.
• Two independent discoveries:
– Reynolds: polymorphism in programming.
– Girard: proof theory of higher-order
arithmetic.
ScottFest 2002
21
Second-Order Logic
• Universals:
• Existentials: 8 . = 8 .(8 .¾ )¾.
ScottFest 2002
22
Program Modules
• Second-order propositional type theory
determines an indexed category P:
– Base: type constructors  :  ) .
– Fibres: proofs/programs t : G !  over D.
– Quantifiers are adjoints to projection.
• A fibred view provides types for higher-order
program modules!
– The “total category”  P of P.
– Package D with terms over D.
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 -> bool
end
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 :
8  ( *  ! bool) !
(t() * t()) ! bool
end
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!: may or may not use argument, may use
many times. Evaluate by-name.
– s!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
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:,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.
– s ² : ordered pair with v:s 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
40