Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
This dissertation is a presentation of the type theoretical foundations for data structures, classes, and objects. The author acknowledges his teachers and mentors who have influenced his interest in mathematics and computer science. The document also includes a list of people who have helped the author in his research and studies. The author also acknowledges the support he received from the DoD Multidisciplinary University Research Initiative (MURI) program administered by the Office of Naval Research (ONR) under Grant N00014-01-1-.
Typology: Thesis
1 / 107
This page cannot be seen from the preview
Don't miss anything!
by Alexei Pavlovich Kopylov January 2004
This document is in the public domain.
Alexei Kopylov was born in Moscow State University on April 2, 1974. His parents were students in the Department of Mathematics and Mechanics there. First year of his life Alexei lived in a student dormitory in the main building of the Moscow State Uni- versity. Then his parents moved to Chernogolovka, a cozy scientific town near Moscow. Alexei returned to Moscow State University as a student in 1991. Five years later he graduated from the Department of Mathematics and Mechanics and entered the graduate school of the same Department. He passed all qualifying exam and almost finish his thesis there, but in 1998 he dropped the graduate school in Moscow and enrolled in the PhD program at Cornell University. Now in January 2004 he is looking forward to move to Caltech as a post doctoral fellow.
iii
I would like to thank here my teachers I had in my life. First of all, I am thankful to my parents Pavel Kopylov and Ekaterina Gamazova. They inculcated in me a taste for mathematics in my early ages. For example, when I was a little boy, my father brought me a pair of sand-glasses. I played with them and came up with different puzzles, like how to measure eleven minutes using sand-glasses for three and ten minutes? My father also taught me programming in Pascal when we did not have a computer. I am also thankful to Raymond Smullyan, although I never met him in person. My early interest in mathematics is partially due to his great book — What Is the Name of This Book? — with logical puzzles about knights and knaves. My father read me the problems from this book (I could hardly read at that time) and I competed with my mother trying to solve the problems first. My special thanks are due to my school math teacher Alexandr Nikolaevich Zem- lyakov “Zemmm”. I admire his mathematical taste and his teaching style. Unfortunately some people who had great influence on me are already passed away. I am very grateful to my grandfather Andrei Konstantinovich Gamazov, who was a great teacher, I am very proud of him. I am also very grateful to my other grandfather Nikolai Georgievivh Kopylov, who taught me chess. My schoolfriend Ivan Soloviev had a big influence on me. He was one year older than me and was always a step ahead of me in mathematical Olympics. I am thankful to my Moscow adviser Sergei Artemov. He helped me a lot both in Moscow and at Cornell. Thanks to him I am here. I owe many thanks to my Cornell adviser Robert Constable for his guidance and many useful discussions. I was very pleased to work with my colleague and namesake (although he spells his name differently) Aleksey Nogin. Part of the thesis is a joint work with Aleksey.
iv
This thesis is done in the framework of a certain constructive type theory, which is an extension of Martin-L¨of type theory. Type theory is powerful tool for formalizing programming languages. It already contains the functional programming language (λ- calculus) and typing systems. The typing system is powerful enough to represent any program specification. In this thesis we research the question of expanding type theory with more programming tools.
One of the important tools of any programming languages is the record type. We also will consider a dependent record type, that is, a record type where the types of com- ponents may depend of previous components (like {x : A; y : B[x]}). Records and especially dependent records are a powerful tool for programming, representing mathe- matical concepts and data structures. In the last decade several type systems with records as primitive types were proposed. We will see that the record type is too complex a type to be primitive, and naive axiomatization leads to contradiction (see Section 4.2). The question arose: whether it is possible to define the record type in existent type theories using standard types without introducing new primitives. It was known that independent records can be defined in type theories with depen- dent functions or intersection. On the other hand dependent records cannot be formed using standard types [5]. Hickey [20] introduced a complex notion of very dependent functions to represent dependent records. Here we extend the constructive type theory with a simpler type constructor dependent intersection , i.e., the intersection of two types,
1
where the second type may depend on elements of the first one (not to be confused with the intersection of a family of types). This new type constructor allows us to define dependent records in a very simple way. Dependent intersection is very simple and natural type constructor. It also allows us to define the set type constructor (which is primitive in the original theory), thus it simplifies the overall type theory. Also it turns out that natural join operator (on) is just an intersection of sets of records.
Another important concept in programming languages is object-oriented programming. Unfortunately object-oriented languages are hard to represent in the type theories due to self-application. (See [1, 17].) In the last decade several encodings of objects in type theory were proposed. See a comparison among the most basic ones in [7]. Almost every existing encoding uses an extension of system F [14] as a target type theory. We show how to embed object types in the constructive type theory using intersec- tion and union. The object encoding in this system has its own specific characters. Objects may have recursive methods. In our system we have total functions. That is, we allow recursive functions as soon as we can prove that they terminate. So we are looking for a definition of a type of objects, such that it allows recursive methods and at the same time allows for a type of objects with a certain method, application of this method to any object of this type should always terminate. Note that in F -like systems application of a method does not necessary terminate. Therefore we can not simply follow the encoding of objects in F -like systems. It also shows that there is no simple
MetaPRL. In Chapter 3 we introduce the new type constructor dependent intersection and show that record types can be defined using this constructor. Even with this new definition of the record type, finding the right elimination rule a for record calculus is challenging. In Chapter 4 we will show that a naive elimination rule for records is contradictory. We will discuss how functionality affects the elimination rule. We also introduce an idea of functions with limited polymorphism. In Section 5.1 we show that our dependent intersection can replace the set type constructor. In Section 5.2 we will show the definition of the variant type which is dual to the record type. In Section 5.3 we show that our record calculus could be used to define abstract algebraic structures. In Section 5.4 we show that natural join operator (on) is just an intersection of sets of records. In Chapter 6 we show an example of an abstract data structure, Set, and give a formally correct implementation of this data structure using red-black trees. In Chapter 7 we encode objects into the type theory.
Our work is done in the setting of constructive type theory as implemented in the Meta- PRL logical framework [22, 19, 23]. Our type theory is an extension of the constructive type theory implemented in NuPRL [8, 9], which is an extension of Martin-L¨of’s type theory [30]. In this chapter we give a short overview of our type theory.
First let us give an overview of the original Martin-L¨of Type Theory [30].
The basic notion in the theory is type. Type is a primitive notion. Two main judgments about types are A Type meaning that A is a type and a ∈ A meaning that a has type A. Each type A is associated with an equality relation on elements of this type, a = b ∈ A. There is also the equivalence relation on types: A = B. So, Martin-L¨of’s type theory has the following four forms of judgments: A Type A is a well-formed type A = B A and B are equal types a ∈ A a has type A a = b ∈ A a and b are equal as elements of type A The examples of types include simple types like Z for integers 0 , 1 , − 1 and B for booleans. We can also construct new types using basic type constructors, like product A × B for the type of pairs 〈a, b〉 and function type A → B for the type of functions
5
and B[x] = [0..x] then x : A × B[x] is a type of pairs of natural numbers 〈n, m〉, where m ≤ n. We can also form a dependent function type x : A → B[x] (also known as a Π- type) which is a type of all functions λx.b[x] where b[a] ∈ B[a] for any a ∈ A. For example, if A = N and B[x] = [0..x] then x : A → B[x] is a type of functions f (n), s.t. 0 ≤ f (n) ≤ n. Dependent types make the theory powerful enough to represent any mathematical statement.
Introduction of a type of all types leads to contradiction (Girard’s paradox [15]). But we can introduce a sequence of universe types U 1 , U 2 ,.... Where U 1 is the universe of the first level, a type of all types constructed without using universes. U 2 is the universe of the second level, a type of all types constructed without using universes of any level above 1. And so on. In this thesis we will assume that we fix some universe level U = Ui, and we will write U′^ for Ui+1 and U′′^ for Ui+2.
In our type theory we derive sequents. Each sequent has a form:
x 1 : H 1 ; x 2 : H 2 [x 1 ];... ; xn : Hn[x 1 ;... ; xn− 1 ] ` C[x 1 ;... ; xn] (2.1)
Here xi’s are declared variables, Hi’s are hypotheses and C is a conclusion. The i-th hypothesis may depend on the variables declared before it, and conclusion may depend on all variables.
Roughly speaking the sequent (2.1) is true when C[x 1 ;... ; xn] is true (i.e. non- empty) for all xi’s from Hi[x 1 ;... ; xi− 1 ]. The formal definition of the truth of the se- quent deals with functionality. Basically, we say that a type C[x] is functional over x : T if t 1 = t 2 ∈ T implies C[t 1 ] = C[t 2 ]. There are different nonequivalent approaches to define what it means for a sequent to be true. Originally Martin-L¨of required that any hypothesis Hi must be functional over previous hypotheses and the conclusion must be functional over all hypotheses. The type theory implemented in NuPRL uses a weaker requirement that allows one to formulate stronger rules (for example a rule for induction over natural numbers). This approach is called pointwise functionality and was discovered by Stuart Allen in [3]. Another version of functionality was used in [31]. Aleksey Nogin later indepen- dently rediscovered it and called it pairwise functionality. In the thesis we will consider pairwise and pointwise functionality.
Pointwise functionality is fairly complicated notion. We will use Aleksey Nogin’s pre- sentation of it. Let we are given a list of hypotheses Γ:
x 1 : H 1 ; x 2 : H 2 [x 1 ];... ; xn : Hn[x 1 ;... ; xn− 1 ].
Then we write ~t for a list of terms t 1 , t 2 ,... , tn. We will also write
~t ∈ Γ[~t ] for ∀i ∈ [1..n]. ti ∈ Hi[t 1 ;... ; ti− 1 ]; ~t = ~t′^ ∈ Γ[~t ] for ∀i ∈ [1..n]. ti = t′ i ∈ Hi[t 1 ;... ; ti− 1 ]; Γ[~t ] = Γ[~t′] for ∀i ∈ [1..n]. Hi[t 1 ;... ; ti− 1 ] = Hi[t′ 1 ;... ; t′ i− 1 ].
On the other hand, the following rule is true in pointwise, but not in pairwise: Γ 1 ; t : T ; Γ 2 [t]; x : A[t]; ∆[x; t] t = t′^ ∈ T Γ 1 ; t : T ; Γ 2 [t]; x : A[t′]; ∆[x; t] C[t; x] Γ 1 ; t : T ; Γ 2 [t]; x : A[t]; ∆[x; t] ` C[t; x]
(P ointwiseSubstitute)
This rule states that we can replace a variable declared as t : T by a term t′^ if we know that t = t′^ ∈ T. Sometimes this rule is stronger than a general substitution rule (which is true in both functionalities). The later rule requires that type A[t] is functional over t : T : Γ; x : A[t]; ∆[x]; z : T A[z] Type Γ; x : A[t]; ∆[x] t = t′^ ∈ T Γ; x : A[t′]; ∆[x] C[x] Γ; x : A[t]; ∆[x] C[x] Rules stated in this thesis are true for both functionalities, unless otherwise men- tioned.
The constructive type theory implemented in MetaPRL has some additional type con- structors, some of them inherited form the NuPRL type theory.
The squiggle equality on terms a ≡ b is defined as the symmetric transitive closure of the reduction relation. Howe showed that it is a congruence [24]. For example we can prove that for any element p of type A × B p ≡ 〈π 1 p, π 2 p〉.
Also we have η-reduction for any f ∈ A → B:
f ≡ λx.(f x)
Our type theory has a primitive type constructor for set types [9]. By definition, the set type {x : T | P [x]} is a subtype of T , which contains only such elements x of T that satisfy property P [x] (see [9]).
Example 2.1 The type of natural numbers is defined as N = {n : Z | n ≥ 0 }. Without set types we would have to define N as n : Z × (n ≥ 0). In this case we would not have the subtyping property N ⊆ Z_._
Later in the thesis (Section 5.1) we will replace this primitive type constructor by more fundamental primitive type, thus simplifying the type theory.
Our type theory also has a subtyping relation [31]. The subtyping relation as well as the membership relation are extensional. That means that A ⊆ B does not say anything about structure of these types, but only means that all elements of type A are also ele- ments of type B and if two elements are equal in A then they are also equal in B. As a result the subtyping relation is undecidable (as well as type checking).
Example 2.2 If A ⊆ B then (B → C) ⊆ (A → C). It may seem strange at a first: suppose A , B and C are finite types and a , b and c are the number of elements in these types correspondingly, then B → C has cb^ elements and A → C has ca^ < cb^ elements. This example shows that a subtype may have more elements than a supertype!
