3.1Lambda Calculus

3.1.1Types

When we think of proofs in the spirit of Heyting, formulae become types. Speci cally:

1.Atomic types T1; : : : ; Tn are types.

2.If U and V are types, then U V and U!V are types.

3.The only types are (for the time being) those obtained by means of 1 and 2.

This corresponds to the (^; )) fragment of propositional calculus: atomic propositions are written Ti, \^" becomes \ " (Cartesian product) and \)" becomes \!".

3.1.2Terms

Proofs become terms; more precisely, a proof of A (as a formula) becomes a term of type A (as a type). Speci cally:

1. The variables xT0 ; : : : ; xTn ; : : : are terms of type T .

2. If u and v are terms of types respectively U and V , then hu; vi is a term of type U V .

3.If t is a term of type U V then 1t and 2t are terms of types respectively U and V .

4.If v is a term of type V and xUn is a variable of type U then xUn : v is a term of type U!V . In general we shall suppose that we have settled questions of the choice of bound variables and of substitution, by some means or other, which allows us to disregard the names of bound variables, the idea being that a bound variable has no individuality.

5. If t and u are terms of types respectively U!V and U, then t u is a term of type V .

3.2Denotational signi cance

Types represent the kind of object under discussion. For example an object of type U!V is a function from U to V , and an object of type U V is an ordered pair consisting of an object of U and an object of V . The meaning of atomic types is not important | it depends on the context.

The terms follow very precisely the ve schemes which we have used for Heyting semantics and natural deduction.

1.A variable xT of type T represents any term t of type T (provided that xT is replaced by t).

2. hu; vi is the ordered pair of u and v.

3.1t and 2t are respectively the rst and second projection of t.

4.xU : v is the function which to any u of type U associates v[u=x], that is v in which xU is regarded as an abbreviation for u.

5.t u is the result of applying the function t to the argument u.

Denotationally, we have the following (primary) equations

together with the secondary equations

which have never been given adequate status.

Theorem The system given by these equations is consistent and decidable.

By consistent, we mean that the equality x = y, where x and y are distinct variables, cannot be proved.

Although this result holds for the whole set of equations, one only ever considers the rst three. It is a consequence of the Church-Rosser property and the normalisation theorem (chapter 4).

3.3Operational signi cance

In general, terms will represent programs. The purpose of a program is to calculate (or at least put in a convenient form) its denotation. The type of a program is seen as a speci cation, i.e. what the program (abstractly) does. A priori it is a commentary of the form \this program calculates the sum of two integers".

What is the relevant part of this commentary? In other words, when we give this kind of information, are we being su ciently precise | for example, ought one to say in what way this calculation is done? Or too precise | is it enough to say that the program takes two integers as arguments and returns an integer?

In terms of syntax, the answer is not clear: for example the type systems envisaged in this book concern themselves only with the most elementary information (sending integers to integers), whereas some systems, such as that of [KriPar], give information about what the program calculates, i.e. information of a denotational kind.

At a more general level, abstracting away from any peculiar syntactic choice, one should see a type as an instruction for plugging things together. Let us imagine that we program with modules, i.e. closed units, which we can plug together. A module is absolutely closed, we have no right to open it. We just have the ability to use it or not, and to choose the manner of use (plugging). The type of a module is of course completely determined by all the possible pluggings it allows without crashing. In particular, one can always substitute a module with another of the same type, in the event of a breakdown, or for the purpose of optimisation.

This idea of arbitrary pluggings seems mathematisable, but to attempt this would lead us too far astray.

A term of type T , say t, which depends on variables x1; x2; : : : ; xn of types respectively U1; : : : ; Un, should be seen no longer as the result of substituting for xi the terms ui of types Ui, but as a plugging instruction. The term has places (symbolised, according to a very ancient tradition, by variables) in which we can plug inputs of appropriate type: for example, to each occurrence of xi corresponds the possibility of plugging in a term ui of type Ui, the same term being simultaneously plugged in each instance. But also, t itself, being of type T , is a plugging instruction, so that it can be plugged in any variable y of type T appearing in another term.

This way of seeing variables and values as dual aspects of the same plugging phenomenon, allows us to view the execution of an algorithm as a symmetrical input/output process. The true operational interpretation of the schemes is still in an embryonic state (see appendix B).