Towards a Set-Theoretic Type Theory - CiteSeerX

Towards a Set-Theoretic Type Theory

Andrzej Borzyszkowski Ryszard Kubiak Jacek Leszczylowski Stefan Sokolowski

y

y

yy

y

September 1988

Introduction Over recent years it has become commonly acknowledged that any programming or speci cation system should be founded on a computer independent type theory. Modern systems need a type theory powerful enough to handle high-order functions, polymorphism and dependent types. A number of approaches have been proposed in this respect, some of them are:

 Girard's & Reynolds's second order typed -calculus [Girard], [Reynolds 74]  early Martin-Lof's type theory [Martin-Lof 73]  recent Martin-Lof's type theory [Martin-Lof 82]  Cardelli's type system [Cardelli]  Nuprl [Constable et al.] Most authors do not care whether or not their types are sets in the classical sense of the term. This has contributed to a widespread belief that classical set theories are useless as a basis for theoretical computer science; cf. for instance the discussion whether the polymorphism is or is not set-theoretic [Reynolds 84], [Pitts]. Polish Academy of Sciences, Institute of Computer Science, Mathematical Methods of Programming Group, c/o Gdansk Division of the PAS, ul. Jaskowa Dolina 31, P.O.Box 562, 80{252 Gdansk, POLAND yyPolish Academy of Sciences, Institute of Computer Science, P.O.Box 22, 00{901 Warszawa PKiN, POLAND y

1

In fact, some of the proposed type theories can be proved not to have any set-theoretic model. Usually this is related to the self-application in one or other form that can be traced in these theories. If the family of all types of a system is decreed to be a type itself, then the Russell's paradox precludes the existence of a set-theoretic model. Out of the ve approaches quoted above only the Martin-Lof's recent type theory and Nuprl are free of the Russell's paradox. The existence of a set-theoretic model, however, is too important feature to be given up. The main goal of this paper is to present such system of sets that may serve as a foundation for denotations of type expressions of a programming language. In this system there is no selfapplication and its existence is consistent with any classical set theory. Still, it is rich enough to contain high-order functions, polymorphism and dependent types. Also recursion operators as well as those needed to build types de ned by recursive equations are present.

1 Basic notions Assume there is a special element ?. Contrarily to some other approaches ? is not required to belong to all sets since this would amount to changing the classical set theory. We only assume ? is neither a set nor a function itself. For any set A by A? is meant the set A [ f?g. Additionally, we assume ?? to be ? even though ? is not a set, so ? [ f?g technically does not make sense. Do not confuse this operation with lifting : for instance (A?)? = A?. Very important for the whole paper is the notion of the generalised Cartesian product Y (1) F:a a2A

If no ?-s are involved, (1) is the set of all total functions f de ned on A such that f:a 2 F:a for all a 2 A (dot is the application of a function to an argument). More generally, if A is a set and F is a function on A such that F:a is either a set or ?, then (1) consists of all total functions f de ned on A such that if F:a = ? then f:a = ? if F:a is a set then f:a 2 F:a Again, (1) is assumed to be ? when A = ?. A typical element of (1) is thus a function that will be denoted by (a 2 A) : : :. 2

A special simpli ed notation is used when the function F in (1) is constant: Y A ! B stands for B a2A

which is the usual set of total functions from A to B . These are simple corollaries of the conventions about ?:

?!A (? ! A)? A!? (A ! ?)?

= = = =

? ? f(a 2 A)?g f?; (a 2 A)?g

In all formulas in this paper we assume that the functional arrow ! binds to the right, thus A ! B ! C is A ! (B ! C ); that the arrow binds stronger than the product, thus Qa2A F:a ! G:a is Qa2A(F:a ! G:a); that the application dot binds to the left, thus x:y:z is (x:y):z; and that application binds stronger than -abstraction, thus (a 2 A)b:c is (a 2 A)(b:c).

2 Systematics of functional dependences Besides simple objects, such as natural numbers or logical values, the type theory in its computer science version makes use of more complex objects. Most of them can be reduced to functions on simple objects, or functions on functions on simple objects, : : : etc. This section is devoted to studying ways the general concept of functional dependence may be used to provide a meaning to the types needed in computer science such as array types, record types, polymorphic types, dependent types etc. It should be viewed as an informal introduction to Sec. 3.1 where all the discussed notions are given de nitions.

3

Throughout this section we assume that we have around = = = = = = = =

Unit T F Bool Error Nat Int Real

f?; hig f?; true g f?; false g T [F f?; error g f?; 0; 1; 2; : : :g f?; 0; ?1; +1; ?2; +2; : : :g

: : : real numbers with added ? : : :

which are primitive types, consisting of primitive (atomic) objects. We assume all of them contain ?, although in this informal section this fact will be disregarded.

2.1 Object{object dependence Assume a collection of types is de ned by the functional closure on primitive types; this means every primitive type is a type, and the set A ! B of functions from A to B is a type, for any two types A and B . In high-order programming languages, unlike in low-order ones, functions are objects. When there is a need to treat functions as objects, low-order languages would supply special constructs. For example,

Array type Most programming languages provide a special construction of array of B indexed by A ; : : :; An, where A ; : : : ; An; B are types. For instance 1

1

(2) a : array[A ; : : :; An] of B 1

in Pascal. The involved types A ; : : : ; An; B have to meet some language-dependent requirements, for instance in Pascal A ; : : : ; An have to be \scalar", which is a technical term of Pascal. Arrays may be viewed as functional objects, for instance a in (2) corresponds to the function 1

1

a0 2 A ! : : : ! An ! B 1

de ned by

a0 : a : : : : : an = a[a ; : : :; an] 1

1

4

for any a 2 A ; : : :; an 2 An. High-order programming languages, such as ML (cf. [ML]), allow such functional objects to be treated as rst-class citizens along with primitive ones (although unlike for the primitive objects, the equality is undecidable). Of course, by the high-order approach no restrictions need to be imposed on the types A ; : : :; An; arrays indexed with arrays translate to functions of functional arguments which make perfect sense. 1

1

1

2.2 Object{type dependence Assume now that a collection of types is de ned by Cartesian rather than by functional closure on primitive types as was the case in the Sec. 2.1. This means primitive types are types, and the set Y a2A

F:a

is a type for any type A and any function F that assigns types to the elements of A. This is more general than in Sec. 2.1 since, as has been stated in Sec. 1, Y A!B = B a2A

To express object{type dependence low-level languages supply special constructors. As an example consider

Records Record types, such as Pascal's Date = record day : Days ; month : Months ; year : Years

end

may be expressed as follows: Y (3) Date = F:a a2(day ;month ;year )

5

where (day,month,year ) is a nite type and

F:day = Days F:month = Months F:year = Years

By de nition (3) any single d 2 Date is a function with domain (day,month,year ) such that

d:day 2 Days d:month 2 Months d:year 2 Years

Functions with varying types of arguments From the point of view of most programming languages, arrays of dierent sizes belong to dierent types which makes impossible to design a de nition of, say, determinant that would correctly perform for square matrices of any sizes (in Algol 60 this was, however, feasible). In our approach the determinant function belongs to the following generalized Cartesian product: Y det 2 Real n2 ! Real n2Nat

which means it takes a natural number n and then \becomes" a function from Real n2 (square matrices of size n, see Sec. 4 for the de nition) to Real .

2.3 Type{object dependences (polymorphic objects) Polymorphism has been introduced into modern programming languages to enable treating families of objects as single objects that may be instantiated to elements of the families. This is why polymorphic objects may be viewed as functions over types. Consider for instance the function stack 2 Type ! Type

that assigns to any type A the type of stacks of elements of A. Usual constructors and destructors of stacks are polymorphic functions: Y push 2 A ! stack.A ! stack.A A2Type

6

pop 2 top 2

Y A2Type

Y

A2Type

stack.A ! stack.A stack.A ! A

These functions may be instantiated (applied) to push.Int 2 Int ! stack.Int ! stack.Int top :(stack.Real ) 2 stack :(stack.Real ) ! stack.Real etc. Some authors, e.g. [Cardelli], distinguish between the parametric polymorphism, in which the dependence on types is as uniform as in the above example, and the ad-hoc polymorphism, such as in: minus 2

Y

A2Type

A!A

de ned as follows: 8 > > > < ?a if A = Real minus:A:a = > :a if A = Bool > > : a otherwise Both kinds of polymorphism are addressed by our approach.

2.4 Type{type dependences (polymorphic types) In Sec. 2.2 we gave examples of how functions yielding types may be used to build types. We shall use the same approach while considering polymorhic (type dependent) types. Consider the function stack 2 Type ! Type ; intuitively, for a given type A it yields the type of stacks over A. It serves as a creator of the following polymorphic type Y (4) stack :A A2Type

Similarly, the function foo 2 Type ! Type

de ned by

0 1 A = Bool ) Int CA foo :A = B @ A 6= Bool ) A def

7

is a creator of the polymorphic type: Y (5) foo :t t2Type

Note that (4) is an example of parametric polymorphism and (5) is an example of ad-hoc polymorphism. We will also distinguish between the shallow and the deep polymorphism. In the above, the family Type of types is the one constructed in Sec. 2.2 by the Cartesian closure of the family of primitive types. This family consists of monomorphic, i.e. non-polymorphic, types. To be able to treat shallow polymorphism i.e. dependence on a number of monomorphic arguments, one has to extend the system to include Y Y A1 2Type

:::

An 2Type

F:A : : :An 1

for any

F 2 Type | ! (Type {z! (: : : ! (Type} ! Type ) : : :)) n

To deal with deep polymorphism one has to add for instance Y f 2Type !Type

F:f

for any

F 2 (Type ! Type ) ! Type This means adding an extra level of functional dependence above Type . This is discussed in length in Sec. 3.1.

3 Hierarchy of types In this section we construct a set-theoretic system of types, rich enough for programming and program speci cations, and we show how the system may be supplied with a partial order for de ning recursion.

8

3.1 Types and objects As described earlier, the main constructor is the generalized Cartesian product, called also dependent product or dependent function space. This leads us to the following

De nition 3.1 Let Prim be a family of sets containing ?. The elements of Prim will be called primitive types. We de ne the set Type of types as the least family of sets such that:

1. f?g 2 Type 2. Prim  Type 3. if A 2 Type and F : A ! Type , then the Cartesian product Qa2A F:a 2 Type 4. if A 2 Type then A? 2 Type 5. if fAi j i = 1; 2; : : :g  Type , then S1i Ai 2 Type =1

This construction is not exible enough to handle polymorphism, i.e. the dependence on types themselves, cf. Sec. 2.4. To allow this the set Type has also to be a member of some type, call it Type . This gets us into a hierarchy of types: Def. 3.1 introduces level-1 types, the set Type is a level-2 type and Type should be de ned as the Cartesian closure of Type [ fType g. As given in the following de nition, the construction is repeated level by level, where levels are natural numbers. 2

2

De nition 3.2 Let ` be a xed natural number. By Type will be meant the set Type. By 1

Type` for ` > 1 will be meant the least family of sets such that:

1. Type `? 2 Type ` 1

2. Type `?  Type ` 1

3. if A 2 Type ` and F : A ! Type ` , then the Cartesian product Qa2A F:a 2 Type ` 4. if A 2 Type ` then A? 2 Type `

5. if fAi j i = 1; 2; : : :g  Type `, then S1i Ai 2 Type ` =1

9

Note that the existence of the families Type ` is consistent with any version of set theory, e.g. the Zermelo-Fraenkel set theory. The self-application present in type systems with TYPE:TYPE is avoided by our hierarchical approach. On the other hand most virtues of such systems are retained by postulating Type ` 2 Type ` (in Sec. 6 we discuss some limitations of the hierarchical approach). The hierarchy is cumulative i.e. Type `  Type ` . The family TYPES which involves all types of our system is de ned by De nition 3.3 TYPES = S1 Type +1

+1

def

`=1

`

The following sets are examples of elements of the family TYPES :

 Nat 2 Type

1

 (Nat ! Nat ) 2 Type  Type ? 2 Type 1

1

2

 (Type ! Type ) 2 Type 1

1

2

 (Qn2Nat if n = 0 then Error else Nat )? 2 Type

1

(provided Nat and Error are in Prim ; the formal de nitions of if: : : then: : : else: : : and : : : = 0 will be provided in Sec. 4, we hope their informal meaning is clear enough). All types are sets, their elements are objects of the following universe : De nition 3.4 OBJECTS = S TYPES They are strati ed in levels by De nition 3.5 Object = S Type `

`+1

for ` = 0; 1; : : :

Of course the above implies

Proposition 3.6 OBJECTS = S1` Object ` =0

Generally speaking, objects are things that may be typed: either primitive objects, or functions, or types. Examples are:

 0 2 Nat 2 Type

1

10

 ((n 2 Nat )n ? 1) 2 (Nat ! Nat ) 2 Type  Nat 2 Type 2 Type 1

1

2

 ((T 2 Type )T ! T ) 2 (Type ! Type ) 2 Type 1

1

1

 ((n 2 Nat ) if n = 0 then error else n ? 1) 2 (Qn2Nat if n = 0 then Error else Nat ) 2 Type

2

1

Primitive objects are elements of elements of Prim , functions are elements of Cartesian products, types are elements of Type n for various n. Since Type n 2 Type n  TYPES , the elements of Type n , i.e. level-n types, are also objects of the universe and can be manipulated. The above is summarized below. +1

Theorem 3.7 The following inclusions hold: 1. Type `  Object `, for ` = 1; 2; : : : 2. TYPES  OBJECTS Now a few examples of sets not belonging to the universe.

 TYPES  Q`2Nat Type `  QT 2TYPES T It may be tempting to add these or similar creatures to the universe but there are strong reasons not to do so. They will be clari ed in Sec. 6.

3.2 OBJECTS as a poset To enable recursive function de nitions one has to introduce in OBJECTS a structure of a partially ordered set. Recursion will be discussed later, in Sec. 5.1. Please note that not every type in TYPES contains ?, for example the product types Y (6) F:a a2A

11

do not; according to the convention from Sec. 1, (6) consists of functions and ? is not a function. Moreover, the primitive types may intersect; and even if they do not, the enumerable union constructor (cf. def. 3.1 p. 5 and def. 3.2 p. 5) makes the types non-disjoint. This precludes a possibility of introducing the order in too naive way. Still, it may be proved that there exists a unique least partial order v in OBJECTS such that

 ? v a for any a 2 OBJECTS  v cut down to any primitive type is the at order on that type, i.e. its non-? elements are incomparable

 any two distinct types A ; A 2 Type `, for any ` = 1; 2; : : :, are incomparable 1

2

 the order v is vertical on function types, i.e. f vf 1

2

i

8a2Af :a v f :a 1

2

for any f ; f 2 Qa2A F:a 1

2

 v cut down to A? is chainwise complete for any type A 2 TYPES ; i.e. there is in A? a unique minimal element, and every ascending chain a v a v a v : : : of elements of A? has a unique least upper bound lub 1i ai 2 A 0

1

2

=0

Note that a type A 2 TYPES without the bottom ? need not be chainwise complete; e.g. Type 2 TYPES and there is no unique minimal element in Type since all its elements are incomparable. For recursively de ned types discussed in Sec. 5.2 we do not need any partial order. 1

1

4 Simple type and program constructors In this section we show examples of type constructors and program constructors one would like to have around, all of them belong to the hierarchy set up in Sec. 3.1. These include equalities, conditionals, binary Cartesian product and constructors and selector for binary Cartesian product. Recursion and type recursion are discussed in Sec. 5. 12

4.1 Equalities There is in OBJECTS a polymorphic eq that upon instantiation with a monomorphic type A takes two A-arguments and yields true or false depending on whether these arguments are equal: Y (7) eq 2 A ! A ! Bool A2Type ?

eq def = (A 2 Type ?) 0 B A=? ) ?

BB BB BB B@

1 1 CC 0 ) ? CC CCC BB a = ? _ a = ? A 6= ? ) (a ; a 2 A) BBB a 6= ? ^ a 6= ? ^ a = a ) true CCC CCC AA @ a 6= ? ^ a 6= ? ^ a = 6 a ) false 1

2

1

2

1

2

1

2

1

2

1

2

If A is ? then the A-coordinate of the Cartesian product in (7) is ? ! ? ! Bool , i.e. ? (see Sec. 1), hence eq :? has to be ? in order to be typed as in (7). The eq above is the level-1 equality since it may be instantiated with a level-1 type A. The same de nition carries over to higher levels giving rise to the following family of eq s: Y (8) eq ` 2 A ! A ! Bool A2Type ?

eq ` def = (A 2 Type ?` ) 0 B A=? ) ?

1 0 1 CC BB ) ? CC CCC BB BB a = ? _ a = ? BB A 6= ? ) (a ; a 2 A) BB CC CC a = 6 ? ^ a = 6 ? ^ a = a ) true B@ B@ CA CA a 6= ? ^ a 6= ? ^ a = 6 a ) false 1

2

1

2

1

2

1

2

1

2

1

2

Obviously, eq = eq . From now on, we are going to write the usual a =`;A a rather than eq ` :A:a :a in case when A 6= ? with the subscript ` omitted whenever it is 1. An omission of the other subscript, A, means that the equality is understood as a meta-predicate. 1

1

13

2

1

2

4.2 Conditionals There is in OBJECTS a polymorphic if that upon instantiation with a monomorphic type A takes a Boolean argument and two A-arguments upon which it produces one of the A-arguments depending on the value of the Boolean argument: Y (9) if 2 Bool ! A ! A ! A? A2Type ?

1 0 A = ? ) ? BB 0 1 CC BB ) ? CC CCC BB b = ? if = (A 2 Type ? )(b 2 Bool ) B BB A 6= ? ) (a ; a 2 A) BB CC B@ B@ b = true ) a CCA CCA b = false ) a def

1

2

1

2

Note that also non-strict functions, like the if above, belong to our hierarchy. The need for non-strict functions is the main reason why we need ? around and are not satis ed with partial functions. The if above is the level-1 conditional since it may be instantiated only with level-1 types. The same de nition carries over to higher levels giving rise to the family of if s: Y (10) if ` 2 Bool ! A ! A ! A? A2Type ?`

0 1 A = ? ) ? B 0 1 CC B B CC b = ? ) ? B B C ? B BB CC CC if ` = (A 2 Type ` )(b 2 Bool ) B B A 6= ? ) (a ; a 2 A) BB b = true ) a CC CC B @ @ AA b = false ) a def

1

2

1

2

Obviously, if = if . The above de ned if s may be used to construct for instance the following object: 1

real-or-error def = (b 2 Bool )if 2:Type:b:Error :Real 2 Bool ! Type ?

is the function that yields Error or Real depending on its Boolean argument. Consider a well known example of division by 0. To describe the exception we need a conditional which yields values in type that depends on its Boolean argument: 0 1 Y @ Y (11) cond 2 A ! A ! (if :Type :b:A :A )?A A1 ;A2 2Type ? b2Bool

1

2

2

14

1

2

cond def =0 (A1; A2 2 Type ? )(b 2 Bool ) BB A1 = ? ) ? BB A 6= ? ) (a 2 A ) 1 1 BB 1 0 BB B A2 = ? ) ? B

1 CC CC CC CC CC CC CC CC A

1 0 1 CC BB ) ? CC CCC BB BB b = ? BB A = B CC B@ 6 ? ) (a 2 A ) BB@ b = true ) a CCA CCA b = false ) a

BB BB BB B@

2

2

2

1

2

This conditional also generalizes to a family of cond s, one for each level `. They can be de ned analogously. Now we can proceed with the example of real-or-error : div def = (r1; r2 2 Real )cond :Error :Real :(r2 =Real 0):error:(r1=r2) 2 Real ! Qr22Real if 2:Type :(r2 =Real 0):Error:Real = Real ! Qr22Real real-or-error :(r2 =Real 0)

is the function that yields its value in Error or in Real depending on whether the denominator is zero. It is an easy observation that if `:A = cond ` :A:A

for any level ` and any A 2 Type `.

4.3 Binary Cartesian product There is in OBJECTS an operation that given two types yields the type that may be looked at as their binary Cartesian product: (12) cart 2 Type ! Type ! Type Y cart = (A ; A 2 Type ) if :Type :b:A :A def

1

2

b2Bool

1

2

2

i.e. cart :A :A consists of functions that given a Boolean argument yield a value in A or in A depending on this argument. 1

2

1

15

2

The standard constructor and destructors for the binary Cartesian product are the objects Y (13) pair 2 A ! A ! cart :A :A 1

A1 ;A2 2Type

2

1

2

pair def = (A1; A2 2 Type )(a1 2 A1)(a2 2 A2)(b 2 Bool )cond :A1:A2:b:a1:a2

(14) fst 2

Y A1 ;A2 2Type

cart :A1:A2 ! A1

fst def = (A1; A2 2 Type )(p 2 cart :A1:A2)p:true

(15) snd 2

Y A1 ;A2 2Type

cart :A1:A2 ! A1

snd def = (A1; A2 2 Type )(p 2 cart :A1:A2)p:false

It is easy to check that, as one might expect (16) fst :A :A :(pair :A :A :a :a ) =A1 a 1

2

1

2

1

2

1

(17) snd :A :A :(pair :A :A :a :a ) =A2 a 1

2

1

2

1

2

2

As has also been the case with conditionals, the above de nitions generalise to higher levels. In most cases we are going to write the somewhat more usual

A ` A 1

2

and

ha ; a i`;A ;A 1

2

1

2

for cart ` :A1:A2

and

pair `:A1:A2:a1:a2

the subscript ` will be often omitted when it is 1.

5 Recursion

5.1 Recursion on objects There is in OBJECTS a general constructor for recursion: Y ? (18) rec 2 (A ! A?) ! A? A2Type

16

rec def = (0A 2 Type )(' 2 (A? ! A?)? ) 1 1 i i B@ f' :? j i = 0; 1; 2; : : :g is a chain ) lub i=0' :? CA otherwise ) ?

The lub above is understood in the sense of the v order discussed in Sec. 3.2. The chain means an ascending sequence of elements. If the functional ' is not ? and if it happens to be continuous then the sequence 'i:? is ascending and rec:A:' is the ''s least xed point, or the least solution of the equation

f = ':f This precisely is the interesting case but rec operates also on non-continuous functionals. As an example of the use of operator rec let us consider the following parity test for natural numbers: (19) even 2 (Nat ! Bool )? even def = rec 1 0 :(Nat ! Bool ): ? (f 2 (Nat ! Bool ) )(n B 0 2 Nat ) 1 CCC B B B f =?)? CA CCA B @if :Bool :(n =Nat 0):true : B@ f = ? ) :f:(n ? 1)

We assume in the above that :? = ?. Since the functional (f: : :): : : above is strictly monotonic, the typing of even in (19) may be improved to even 2 Nat ! Bool

i.e. even itself is not ?. Since the functional is continuous, the above de ned even is the least function such that even :n = if :Bool :(n =Nat 0):true :(:even :(n ? 1))

Recall that ? is not a function, therefore the application ?:a is technically incorrect. Still, for simplicity, we are going to write f:a instead of 0 1 B@f = ? ) ? CA f 6= ? ) f:a 17

as this should not lead to confusion. The de nition of rec carries over to higher levels. The example function cartpow de ned below given a natural number n becomes a function in Type ! Type that given a type A yields its n -th Cartesian power An: cartpow 2 (Nat ! Type ! Type ? )?

Since Nat ! Type ! Type ? is a level-2 type, the function rec has to be used: 2

cartpow def =0 rec 2:(Nat ! Type ! Type ?): BB(f 2 (Nat ! Type ! Type ? )?)(n 2 Nat )(A 2 Type ) BB if :Type:(n =Nat 0):Unit : BB 0 2 1 BB Bif 2:Type :(n =Nat 1):A: 1 CCC BB BB0 BB BBBf:(n ? 1):A = ? ) ? CA CCA @ @@ f:(n ? 1):A 6= ? ) Af:(n ? 1):A

1 CC CC CC CC CC CC A

Again it can be shown that cartpow 2 Nat ! Type ! Type ?. Note that by virtue of the de nitions introduced so far, cartpow :?:A = ? for any A 2 Type . And this is yet another example: given a natural number n , a type A and an element a in A the function tuple produces the following values: ? for n = ?, hi for n = 0; a for n = 1; and

h|a; ha;{z: : : ha}; ai : : :ii n?1 times

for n > 1. This is the de nition of the function tuple : Y Y tuple 2 A ! cartpow :n:A n2Nat A2Type

(20) tuple = Q Q rec : ( n 2 Nat A2Type A ! cartpow :n:A): 1 0 Q Q ? BB(f 2 ( n2Nat A2Type A ! cartpow :n:A) )(n 2 Nat )(A 2 Type )(a 2 A) CC CC BB if :(cartpow :n:A):(n = 0):hi: Nat CA B@ (if :(cartpow :n:A):(n =Nat 1):a:ha; f:(n ? 1):A:aiA;cartpow : n? :A) def

(

18

1)

5.2 Recursive type de nitions To give a meaning to the recursive de nitions of types we shall use \iterated union" operator. There is in OBJECTS a general constructor for recursively de ned types: (21) iter union 2 (Type ! Type ) ! Type 1 [ iter union = ( 2 Type ! Type ) i :f?g def

i=0

In case  is continuous with respect to the set inclusion (look out: a dierent order than in Sec. 5.1 !) and has the property that A  (A) for any A 2 Type , iter union : is its least xed point: iter union : = :(iter union :)

But iter union is also de ned for non-continuous functionals. This will be discussed in more detail in a dierent paper. A typical example of a recursively de ned type is provided by sequences. Let  = (A 2 Type )(X 2 Type )Unit [ A  X def

Then seq 2 Type ! Type seq def = (A 2 Type )iter union :(:A)

Since  is continuous, the above de ned seq is the least such that seq :A = Unit [ A  seq :A

The de nition of iter union readily generalizes to higher levels. (22) iter union ` 2 (Type ` ! Type `) ! Type ` 1 [ iter union ` = ( 2 Type ` ! Type ` ) i:f?g def

i=0

19

6 Final remarks The presented system of sets is intended as a core of an algebra of denotations of a high level programming language. In fact, one would like to have more primitive types in Prim as well as more type building operators. Such extensions will be investigated in future papers.

6.1 Limitations of the hierarchical view In Sec. 4 we have mentioned the existence of if `; cond ` cart ` ; pair ` ; fst `; snd ` rec ` iter union `

for any level `. The reader may feel annoyed by having always to care about the level indicators when writing formulae and equations that concern the above objects. Admittedly, they easily generalise onto the whole hierarchy; for instance if `1 :A = if `2 :A

for any levels ` and ` such that ` < ` and for any A 2 Type`1  Type`2 . This accounts for the correctness of the following de nition of the \superobject" if ! : Y if ! 2 Bool ! A ! A ! A? 1

2

1

2

A2TYPES ?

if ! :A def = if `:A

where ` is suciently high in order that A 2 Type `. Other superobjects cond ! , cart ! , : : : may be de ned alike. Note however that the superobjects are not elements of OBJECTS, therefore they are not in our universe. The universe might be very well extended to trans nite levels: Type ! def = TY PES Type !+`+1 def = Cartesian closure of Type !+` [ fType !+` g

20

for ` = 0; 1; 2; : : :

Type !+! def =

1 [ `=0

Type !+`

but this would give rise to a proliferation of \supersuperobjects" that would still escape the classi cation, but could in their turn be enclosed in a still higher hierarchy, etc. One can never end up with everything conceivable already in, as has been the case e.g. in the Cardelli's TYPE:TYPE approach, without getting back into the Russell's paradox. This trans nite \race with no winner" is the price for the existence of a set-theoretic model. The trans nite hierarchy can be however cut down at an arbitrary selected point. We have chosen to retain all elements of OBJECTS and to leave out superobjects. This re ects our belief that the rst two or three levels are in fact all that is needed for most applications.

6.2 Relation to other type systems There are basically three dierent approaches to more sophisticated type systems: 1. operational | as in Pebble language (see [Burstall&Lampson]) 2. constructive | Martin-Lof, Girard, Nuprl 3. model theoretic | ML's and our approach. The important feature of the Pebble type system is that TYPE:TYPE. This exludes it from set-theoretic scope (Russell's paradox). Somewhere between 1 and 2 is Cardelli's type system which, while including the paradox, is trying to bridge these two. An interesting (similar to our) cumulative hierarchy of types is the Nuprl type system. It is done in the spirit of Martin-Lof's theory and is based on constructive basis. The elements of types are terms but in contrast to set theory two types with the same elements may be dierent due to the way the equality relation over types has been de ned. The ML type system can be embeded in our hierarchy, see [Borzyszkowski&Kubiak&Sokolowski].

6.3 Conclusions The interest in type theories is twofold. On one hand they are useful in organizing and clarifying programming and/or speci cation language constructs. On the other hand they serve as a basis for type checking. 21

Our study was motivated by both aspects. We have tried to model polymorphism and dependent types as well as to give some tools for recursive de nitions of functions and types. The resulting hierarchy originates also from our belief that the theory should be simple and involve very few primitive concepts. As such it can serve as a foundation for any programming or speci cation language. In fact, our study was also motivated by needs of our group's MetaSoft project, currently under design. One part of the project is a speci cation language with an elaborated type system.

References [Beeson]

Michael J. Beeson. Foundations of Constructive Mathematics . Ergebnisse der Mathematik und ihrer Grenzgebiete, Springer-Verlag, 1985.

[Borzyszkowski&Kubiak&Sokolowski] Andrzej Borzyszkowski, Ryszard Kubiak and Stefan Sokolowski. \A set-theoretic model for a polymorphic typed -calculus. A contribution to MetaSoft". [Breazu-Tannen&Coquand] Val Breazu-Tannen and Thierry Coquand. \Extensional models for Polymorphism". In Proc.TAPSOFT'87. LNCS 250, 1987, pp. 291{307. [Bruce&Meyer]

Bruce K.B. and A.R. Meyer. \The semantics of second order polymorphic -calculus". In Kahn G., MacQueen D.B. and G. Plotkin eds. Semantics of Data Types , LNCS 173, 1984.

[Burstall&Lampson] Rod Burstall and B. Lampson. \A kernel language for abstract data types and modules". In Kahn G., MacQueen D.B. and G. Plotkin eds. Semantics of Data Types , LNCS 173, 1984. [Cardelli]

Luca Cardelli. \A Polymorphic -calculus with Type:Type". Digital, System Research Center, Palo Alto, California, Report #10.

[Constable et al.] Robert Constable et al.. Implementing Mathematics with the Nuprl Proof Development System. Graduate Text in Mathematics vol. 37, Prentice-Hall, 1986. 22

[Coquand et al.] Thierry Coquand, Carl Gunter and Glynn Winskel. \Domain Theoretic Models of Polymorphism". Univ. of Cambridge, Computer Laboratory, Technical Report no. 116. [Girard]

J-Y. Girard. \Interpretation fonctionelle et elimination des coupures dans l'aritmetique d'ordre superieure". These d'Etat, Universite Paris VII, 1972.

[Martin-Lof 73]

Per Martin-Lof. \An intuitionistic theory of types: predicative part". In Rose F. and J. Sheperdson, eds. Logic Colloquium'73 , North-Holland, Amsterdam, 1973, pp. 73{118.

[Martin-Lof 82]

Per Martin-Lof. \Constructive Mathematics and Computer Programming". In Proc.Sixth International Congress for Logic, Methodology and Philosophy of Science, North-Holland, Amsterdam, 1982

[Meyer]

Alber R. Meyer. \What is a model of the -calculus?" Information and Control 52(1), pp. 87{122.

[Meyer&Reinhold] Albert R. Meyer and Mark B. Reinhold. \ `Type' Is Not a Type: Preliminary Report". Proc.POPL 1986. [ML]

\Functional programming in ML". LFCS Education, Dept. of Computer Science, University of Edinburgh, 1986

[Pitts]

Andrew Pitts. \Polymorphism is set-theoretic, constructively". In Category Theory and Computer Science , Edinburgh, September 1987, Lecture Notes in Computer Science, Springer-Verlag, 1987.

[Reynolds 74]

J.C. Reynolds. \Towards a theory of type structure". In B.Robinet, ed. Colloquium sur la programmation , LNCS 19, 1974, pp. 408{425.

[Reynolds 84]

J.C. Reynolds. \Polymorphism is not set-theoretic". In Kahn G., MacQueen D.B. and G. Plotkin eds. Semantics of Data Types , LNCS 173, 1984.

23