Beruflich Dokumente
Kultur Dokumente
Abstract.
The constructive meaning of mathematical propositions makes it possible to identify specifica-
tions for computer programs with propositions. In Martin-L6fs type theory, constructing a pro-
gram satisfying a specification corresponds to proving the proposition expressing the specification.
These ideas are explained and some examples of specifications are given.
1. Introduction.
natural in the sense that they should allow simple formalization of intuitive
reasoning. That traditional programming languages are very far from this
requirement is illustrated by O'Donnell [19], who has some examples of
published incorrect rules for a weak imperative language containing only
assignments, conditionals, while-statements and function definitions.
In mathematical logic, formal languages in which one can express substantial
parts of mathematics have a long history, going back to Frege's Begriffsschrift
from 1879. So, if we want a programming language in which it should be
possible not just to write down programs but also to reason about them, an
obvious attempt is to see whether any of the formalizations used for
mathematics could also be used for programming.
Today, the standard formalization of classical, i.e. nonconstructive,
mathematics is the axiomatization of set theory given by Zermelo in 1908.
However, there is no notion of computation in classical set theory. So, using a
formalization of nonconstructive set theory for programming involves a serious
problem: there is no natural way of representing programs. For instance, the
notion of function cannot be used because functions in classical set theory are in
general not computable.
Out of the foundational crisis of mathematics in the first decades of this
century, constructive mathematics arose as an independent branch of
mathematics, mainly developed by Brouwer under the name intuitionism.
Constructive mathematics did not get much support because of the general
belief that important parts of mathematics were impossible to develop
constructively. By the work of Bishop, however, this belief has been shown to be
mistaken. In his book "Foundations of constructive analysis" [2], he
constructively rebuilds central parts of classical analysis; and he does it in a
way that demonstrates that constructive mathematics can be as simple and
elegant as classical mathematics. Bishop [3] also envisaged the possibility of
using a formalization of constructive mathematics for programming, starting
from G6ders [9] theory of computable functionals of finite type. Constable [6],
Goto [8], Sato [21], and Takasu [26] have also proposed constructive
mathematics as a foundation of programming.
Martin-L6fs type theory [14] was developed with the aim of being a
formalization of constructive mathematics. Its rules are formulated in the style
of Gentzen's natural deduction system for predicate logic, a formal system
which Gentzen set up in 1934 with the intention that it should be as close as
possible to actual reasoning. Martin-L6f [16] has suggested that type theory
also could be viewed as a programming language. As such it is a typed
functional language without assignments or other imperative features.
-Compared with other programming languages, it has a very rich type structure
in that the type of a program can be used to completely specify the task of the
program; it can be used to describe what the program should do without
describing how the program performs its task. This is in contrast with, for
290 BENGT NORDSTROM AND JAN SMITH
If we denote the left projection by fst, i.e.fst((a, b)) = a where (a, b) is the pair
PROPOSITIONS AND SPECIFICATIONS OF PROGRAMS I N . . . 291
xisaproofofA & B.
fst(x) is a proof of A.
Hence, 2x .fst(x) iisa function which to each proof of A and B gives a proof A,
i.e. Ax .fst(x) is a proof of A & B D A.
The idea behind propositions as types is to identify a proposition with the
type of its proofs. That a proposition is true then means that its corresponding
type is nonempty. For implication and conjunction we get, in view of the
explanations above,
and
Using the 2-notation, the objects of A ~ B are of the form 2x.b(x), where
b(x)~ B when x e A, and the objects of type A x B are of the form (a, b) where
a e A and b~B.
These identifications may seem rather obvious, but they were not observed
until Curry [7], and then only as a formal correspondence of the types of the
basic combinators and logical axioms for a language only involving implication.
This was extended to first order intuitionistic arithmetic by Howard [11] in
1969. Similar ideas also occur in de Bruijn [4] and Lauchli [14]. Scott [22] was
the first to suggest a theory of constructions in which propositions are
introduced as types. The idea of using constructions to represent proofs is also
related to recursive realizability interpretations, first developed by Kleene [12]
for intuitionistic arithmetic and extensively used in metamathematical
investigations of constructive mathematics.
These ideas are incorporated in Martin-L6fs type theory, which has enough
types to express all the logical constants. In particular, type theory has function
types and cartesian products which, as we have seen, make it possible to express
implication and conjunction. Let us now see what type forming operators are
needed for the remaining logical constants.
A disjunction is constructively true only if we can prove one of the disjuncts.
So a proof of A v B is either a proof of A or a proof of B together with an
indication of which disjunct we have a proof of.
292 BENGT NORDSTROM AND JAN SMITH
Hence,
The objects of A + B are of the form inl(a) and inr(b), where a e A and be B.
The negation of a proposition A can be defined by
7A-A~
where .1. stands for absurdity, i.e. the proposition which has no proof. If we let
q~ denote the empty type, we have that
The objects of (I'IxEA)B(x) are of the form ~x.b(x) where b(x)eB(x) when
x~A.
PROPOSITIONS AND SPECIFICATIONS OF PROGRAMS I N . . . 293
Except the empty type, we have not yet introduced any types that correspond
to atomic propositions. One such type is the equality type a =a b, which
expresses that a and b are equal objects of type A. Recalling that a proposition
is identified with the type of its proofs, we see that this type has to be nonempty
if and only if a and b are equal. If a and b are equal objects of type A, we
postulate that the constant e is the only object of the type a =Ab. This is
similar to recursive realizability interpretations of arithmetics where one usually
lets the natural number 0 realize a true atomic formula.
Besides the types for interpreting logic, there are, of course, the usual types
needed for programming: natural numbers, lists and enumeration types like
Boolean. There are also other ways of introducing types. For instance, types
may be defined by primitive recursion. As an example, a type F(n) depending on
n e N , where N is the type of natural numbers, may be introduced by the
recursion
r(o) = N
F(succ(n)) = N ---}F(n)
(4) fst(z) e A
and
Here fst(z) corresponds to the object a in the proof of (1) above and snd(z) is a
proof of (Vy e B)C(a, y). Assume that
(6) y e B.
which corresponds to the truth of (gx e A)C(x, y). Since (8) is derived from the
assumption (6), we get
i.e., we have constructed, from the assumption (3), an object of the type
corresponding to the proposition (Vy e B)(gx e A)C(x, y). Since (9) is derived
from the assumption (3), we finally get
2z. 2y. (fst(z), ap(snd(z), y))e ((Zx e A)(1-ly e B)C(x, y) ~ (Fly e B)(~,x e A)C(x, y)).
The steps in this proof are all in accordance with the formal rules of type
theory.
Note that, in this example, we have used the word proof for two different
notions. First, for an object of a type corresponding to a proposition and,
second, for a derivation that an object is of a certain type. For a detailed
discussion of this important distinction, we refer to Sundholm [25].
This explanation of the logical constants can be used to specify the task of a
program in the following way.
A & B is a specification of programs which, when executed, yield a pair (a, b),
where a is a program for the task A and b is a program for the task B.
(3xe A)B(x) specifies programs which, when executed, yield (a, b), where a i's
an object of A and b a program for B(a). So, to solve the task (3xeA)B(x), it is
necessary to find an object a of A such that B(a) holds
fst(ap(ap(f, x ), y ) )
snd(ap(ap(f, x), y)
3.2. A compiler
Considering the restricted case where all programs in the source and target
languages terminate, the general task of a compiler can be specified in the
following way. Let all programs in the source language be represented by
objects of a type L and all programs i n t h e target language by objects of a type
I'. It is convenient to let the representation be some kind of tree structure
corresponding to the abstract syntax of the program, but the actual
representation is immaterial for our purpose. Assume that the operational
semantics of the languages are given by M and M', interpreters for L and /~,
PROPOSITIONS AND SPECIFICATIONS OF PROGRAMS I N . . . 297
respectively. Hence
M(s) e (I ~ O) when s ~ L
M'(t) ~'(I --* O) when t e E
where the equality between the two functions M(s) and M'(t) means that
ap(M(s), i) = ap(M'(t), i) for all inputs i. We can illustrate this by the commuting
diagram
c
L ....... ~L
1~0
If we prove the proposition (1) in type theory, we get a construction f such that
c - 2s. fst(ap(f,s)).
There is no hope that the specification (1) is executable for nontrivial languages.
It should also be noticed that the specification does not determine the translated
program s uniquely from a given program t. So two compilers producing
different codes both satisfy the specification. In the transformational approach
[5], the specification defines the target programs in terms of the given source
298 BENGT NORDSTROM AND JAN SMITH
3.3. K W I C - i n d e x generation
This example is a specification of a problem from a workshop on Program
Specification [24] which was held in Aarhus, Denmark, in August 1981. The
informal specification is copied from the proceedings of the conference.
3.3.1. INFORMALSPECIFICATION
Consider a program which generates a K W I C index (keyword in context). A
title is a list of words which are either significant or nonsignificant. A rotation of
a list is a cyclic shift of the words in the list, and a significant rotation is a
rotation in which the first word is significant. Given a set of titles and a set of
nonsignificant words, the program should produce an alphabetically sorted list
of the significant rotations of the titles.
titles
T H E T H R E E L I T T L E PIGS.
S N O W W H I T E A N D T H E SEVEN DWARVES.
nonsignificant words
THE, T H R E E , AND, SEVEN
should produce :
DWARVES. SNOW W H I T E AND T H E SEVEN
L I T T L E PIGS. T H E T H R E E
PIGS. T H E T H R E E L I T I ' L E
S N O W W H I T E A N D T H E SEVEN DWARVES.
W H I T E AND T H E SEVEN DWARVES. S N O W
3.3.2 FORMALSPECIFICATION
Suppose that we have an enumeration type Printable_char which is a subset
of the enumeration type Ascii.
A title is a list of words:
Title - List(Word)
Word -- List(Printable_char).
An dement in the type Title' is a pair, the first component being a nonempty list
of words and the second component a proof that the first component is
nonmpty. A rotation of a list is a cyclic shift of the elements in the list. We can
define Rotation(y, t), the proposition that y is a rotation of t, in the following
way:
shift(nil) = nil
shift(a, s) = s<> (a. nil)
f(x) = x
f"+ l(x) = f ( f " ( x ) )
nil <> y = y
a . s < > y = a. (s<>y).
Orderedlnil) = _1_
Ordered(a. nil) = _L
Ordered(a . b . s) = Lex(Word)(Lex(Printable_char)(())(a, b ) & Ordered(b . s).
We have now made enough definitions to be able to formally specify the kwic
program.
Given a list t of titles and a list n of nonsignificant words, the program should
produce an alphabetically sorted list of significant .rotations of the titles. This
means that the output should be ordered and a list of words should appear as
an element in the output if and only if it is a significant rotation of some title in
the input, i.e. if we assume that t~ List(Title), n~ List(Word), then a proof of the
proposition
where
A . ~ B - (A D B ) & (B ~ A)
would yield a pair whose first component has the properties we are looking for.
A complete specification of the task of the kwic program is now given by the
proposition
This specification does not say how to solve the problem, but if we prove this
proposition in type theory we would obtain a function f which when applied to
a list of titles t and a list n of words gives a pair. The first component of the pair
is the desired result, i.e.
1. J. Backus, Can programming be liberatedfrom the yon Neuman style ? A functional style and its
algebra of programs, Comm. ACM, Vol. 21 no. 8 pp. 613-641 (August 1978).
2. E. Bishop, Foundations of Constructive Analysis, McGraw-Hill, New York (1967).
3. E. Bishop, Mathematics as a numerical language, pp. 53-71 in Intuitionism and Proof Theory,
ed. Myhill, King, Vesley, North Holland, Amsterdam (1970).
4. N. G. de Bruijn, A Survey of the project Automath, pp. 579-606 in To H. B. Curry: Essays on
Combinatory Logic, Lambda Calculus and Formalism, ed. J. P. Seldin and J. R. Hindley,
Academic Press, London (1980).
5. R. M. Burstall and J. Darlington, A transJbrmation system .[br developing recursiveprograms, J.
of the ACM, Vol. 24 no. 1 (January 1977).
6. R. L. Constable, Constructive mathematics and automatic program writers, pp. 229-233 in
Proceedings of IFIP Congress, North-Holland, Ljubljana (1971).
7. H. B. Curry and R. Feys, Combinatory Logic, Vol. 1, North-Holland, Amsterdam (1958).
8. S. Goto, Program Synthesis from Natural Deduction Proofs, IJICAI 1979, Tokyo.
9. K. G6del, ~)bereine bisher noch nicht beniitzte Erweiterung des finiten Standpunktes, Dialeetiea,
Vol. 37 pp. 280-287 (1958).
I0. A. Heyting, Intuitionism, an Introduction, North-Holland (1956).
11. W. A. Howard, The Formulae-as-types notion of construction, pp. 479490 in To H. B. Curry:
Essays on Combinatory Logic, Lambda Calculus and Formalism, ed. J. P. Seldin and J. R.
Hindley, Academic Press, London (1980).
12. S. C. Kleene, On the interpretation of intuitionistic number theory, Journal of Symbolic Logic,
Vol. 10 pp. 109-124 (1945).
13. A. N. Kolmogorov, Zur Deutang der intuitionistischen Logik, Mathematische Zeitschrift, Vol. 35
pp. 58-65 {1932).
14. H. Lauchli, An abstract notion of realizabiHtyfor which intuitionistic predicate logic is complete
in Intuitionism and Proof Theory, ed. Myhill, King and Vesley, North Holland, Amsterdam
(1970).
15. P. Martin-LOf, An intuitionistic theory of types: predicative part, pp. 73-118 in Logic
Colloquium 1973, ed. H. E. Rose and J. C. Shepherdson, North-Holland, Amsterdam (1975).
16. P. Martin-LOf, Constructive mathematics and computer programming, pp. 153-175 in Logic,
Methodology and Philosophy of Science, VI, North-Holland Publishing Company, Amsterdam
(1982), Proc. of the 6th Int. Cong., Hannover, 1979.
17. B. NordstrOm, Programming in constructive set theory: some examples in Proc. ACM 1981
Conference on Functional Languages and Computer Architecture, Wentworth-by-the-Sea,
Portsmouth, New Hampshire (October 1981).
18. B. NordstrOm, K. Petersson, and J. Smith, An Introduction to Type Theory, Programming
Methodology Group, Chalmers University of Technology, GOteborg. In preparation.
19. M. J. O'Donnell, A Critique of the Foundations of Hoare-style Programming Looic, CACM,
Vol. 25 no. 12 pp. 927-934 (Decembe.r 1982).
20. K. Petersson, A Programming System for Type Theory, Memo 21, Programming Methodology
Group, Chalmers University of Technology, GOteborg (1982).
21. M. Sato, Toward a mathematical theo.ry of program synthesis, Proc. of the 6-th IJICAI 1979.
22. D. Scott, Constructive validity, pp. 237-275 in Symposium on Automatic Demonstration,
Lecture Notes in Mathematics, Vol. 125, Springer Vedag, Berlin (1970).
23. J. Smith, The identification of propositions and types in Martin-l.,OJ~s type theory: A
programming example in International Conference on Foundations of Computation Theory,
Borgholm, Sweden (August 2t-27, 1983). Lecture notes in Computer Science, Vol. 158,
Springer Vedag.
24. J. Staunsrup, Proceedings of a Workshop on Program Specification, Aarhus, Denmark (August
1981). Lecture Notes in Computer Science, Vol. 134, Springer Verlag.
25. G. Sundholm, Constructions, proofs and the meaning of the logical constants, Journal of
Philosophical Logic 12 (1983) pp. 151-172.
26. S. Takasu, Proofs and Programs, Proc. of the 3rd IBM Syrup. on Math. Foundations of
Computer Science 1978, IBM Japan.