Dependent Intersection: A New Way of Defining Records in ∗

Alexei Kopylov Department of Computer Science Cornell University Ithaca, NY 14853, USA

Abstract T [x1, . . . , xn] for expressions that may contain free vari- ables x1,..., xn (and probably some other free variables), Records and dependent records are a powerful tool and T [t1, . . . , tn] for substitution terms ti’s for all free oc- for programming, representing mathematical concepts, and currences of xi’s). program verification. In the last decade several type sys- Martin-Lof’s¨ type theory has the following judgments: tems with records as primitive types were proposed. The A Type A is a well-formed type question is arose: whether it is possible to define record A = BA and B are (intentionally) equal types type in existent type theories using standard types without a ∈ A a has type A introducing new primitives. a = b ∈ A a and b are equal as elements of type A It was known that independent records can be defined in The NuPRL type theory also has relation. Al- type theories with dependent functions or intersection. On though it is not essential for our work, we should mention the other hand dependent records cannot be formed using that membership and subtyping in NuPRL are extensional. standard types. Hickey introduced a complex notion of very For example, A ⊆ B does not say anything about struc- dependent functions to represent dependent records. In the ture of these types, but only means that if x ∈ A then current paper we extend Martin-Lof’s¨ type theory with a x ∈ B. As a result the type checking and subtyping are simpler dependent intersection, i.e., the in- undecidable. On the other hand, type equality (A = B) is tersection of two types, where the second type may depend intensional. We will use A =e B for extensional equality: ∆ on elements of the first one (not to be confused with the in- A =e B = (A ⊆ B)&(B ⊆ A). tersection of a family of types). This new type constructor The NuPRL type theory has also an intersection type. allows us to define dependent records in a very simple way. The intersection of two types A and B is a new type con- It also allows us to define the type constructor. taining elements that are both in A and B. For example, λx.x + 1 is an element of the type (Z → Z) ∩ (N → N). Two elements are considered to be equal as elements of the 1 Introduction type A ∩ B if they are equal in both types A and B.

− 1.1 Type Theory Example 1 Let A = N → N and B = Z → Z (where Z− is a type of negative integers). Let id be λx.x and abs We will use the NuPRL type theory [6], which is an ex- be λx.|x|. Then id and abs are both elements of the type tension of Martin-Lof’s¨ type theory [16]. Martin-Lof’s¨ type A∩B. Although id and abs are equal as elements of the type theory allows dependent types. That is, type expression may N → N (because these two functions do not differ on N), id − contain free variables ranging over arbitrary types. For ex- and abs are different as elements of Z → Z. Therefore, ample, we can form an expression T [x] = [0..x] which rep- id 6= abs ∈ A ∩ B. resents an initial sequent of natural numbers. This expres- In Martin-Lof’s¨ type theory types are first-class objects. sion is a type when x ∈ N. (Some notations: we will use There is the universe type U that contain types that were ∗This work was supported in part by the DoD Multidisciplinary Uni- formed without using of U. versity Research Initiative (MURI) program administered by the Office Our work is implemented in a setting of the NuPRL type of Naval Research (ONR) under Grant N00014-01-1-0765, the Defense Advanced Research Projects Agency (DARPA) under Grant F30602-98-2- theory, namely in the MetaPRL system [12, 13] . See the- 0198, and by NSF Grant CCR 0204193. ories itt disect and itt record in Logical Theories

1 in [13]. All proofs except the proof of the semantical The- treat the record type as a new primitive. In the current pa- orem 10 are machine-checked. We believe that most of our per we are interesting in the following natural question: is results could be adapted to any type theory that allows bi- it possible to express the notion of records in usual type the- nary intersection and dependent types. ories without record type as primitives? This question is especially interesting for pure mathematical proof systems. 1.2 Records As we saw records are a handy tool to represent algebraic structures. On the other hand records do not seem to be In general, records are of labeled fields, where the basic mathematical concept that should be included in each field may have its own type. In dependent records the foundation of mathematics. Records should be rather (or more formally dependently typed records) the type of defined in terms of more abstract mathematical concepts. components may depend on values of the other components. It is known that it is possible to define independent Since we have the type of types U, values of record compo- records in a sufficient powerful type theory that has depen- nents may be types. This makes the notion of dependent dent functions [11] or intersection [21]. On the other hand, records very powerful. Dependent records may be used to there is no known way to form dependent records in stan- represent algebraic structures (such as groups) and modules dard Martin-Lof’s¨ type theory [4]. However, Hickey [11] in programming languages like SML or Haskell (see for ex- showed that dependent records can be formed in an exten- ample [3, 10]). sion of Martin-Lof’s¨ type theory. Namely, he introduced a new type of very dependent functions. This type is pow- Example 2 One can define the signature for ordered set as erful enough to express dependent records in a type the- a dependent record type: ory and provides a mathematical foundation of dependent records. Unfortunately the type of very dependent func- OrdSetSig = {t : U; less : t → t → Bool} tions is very complex itself. The rules and the semantics This definition can be understood as an algebraic structure probably is more complicated for this type than for depen- as well as an of a module in a programing lan- dent records. The question is whether there is a simpler way guage. to add dependent records to a type theory. In this paper we extend the NuPRL type theory with a Example 3 The proposition-as-type principle allows us to simpler and easier to understand primitive type constructor, add the property of ordered sets as a new component: dependent intersection. This is a natural generalization of the standard intersection introduced in [8] and [20]. Depen- OrdSet={t:U; less:t → t → Bool; axm : Ord(t, less)} dent intersection is an intersection of two types, where the where Ord(t, less) is a predicate stating that less is a second type may depend on elements of the first one. This transitive irreflexive relation on t. Here axm is a new field type constructor is built by analogy to dependent products: that defines the axiom of the algebraic structure of ordered elements of dependent product are pairs where the type of sets (or specification of the module type OrdSet). the second component may depend on the first component. We will show that dependent intersection allows us to de- Example 4 In type theories with equality, manifested fine the record type in a very simple way. Our definition of fields ([15]) may be also represented as specification. records is extensionally equal to Hickey’s ones, but is far simpler. Moreover our constructors (unlike Hickey’s) allow IntOrdSetSig = {t:U; less:t→t→Bool; mnf:t=Z} us to extend record types. For example, having a definition of monoids we can define groups by extending this defini- is a signature where t is bound to be the type of integers. tion rather than repeating the definition of monoid. From a mathematical point of view the record type is similar to the . The essential difference is 1.3 The Set Type Constructor the subtyping property: we can extend a record type with new fields and get a subtype of the original record type. The NuPRL type theory has a primitive type constructor E.g. OrdSet and IntOrdSetSig defined above are sub- for subset types. By definition, the set type {x : T | P [x]} types of OrdSetSig. The subtyping property is important is a subtype of T , which contains only such elements x of in mathematics: we can apply all theorems about monoid’s T that satisfy property P [x] (see [6]). to smaller types such as groups. It is also essential in pro- graming for inheritance and abstractions. Example 5 The type of natural numbers is defined as N = Different type theories with records were proposed {n : Z | n ≥ 0}. Without set types we would have to define both for proof systems as well as for programming lan- N as n : Z × (n ≥ 0). In this case we would not have the guages ([10, 15, 9, 3, 4, 19] and others). These systems subtyping property N ⊆ Z.

2 It turns out that dependent intersection can be also used Γ ` A Type Γ; x : A ` B[x] Type to define a set type. This means that dependent intersection Γ ` (x : A ∩ B[x]) Type not only adds support for dependent records, it simplifies the overall the NuPRL type theory at the same time. Γ ` A = A0 Γ; x : A ` B[x] = B0[x] 2 Dependent Intersection Γ ` (x : A ∩ B[x]) = (x : A0 ∩ B0[x])

We extend the definition of intersection A ∩ B to a case Type when type B can depend on elements of type A. Let A be a Γ ` a ∈ A Γ ` a ∈ B[a]Γ ` x : A ∩ B[x] type and B[x] be a type for all x of type A. We define a new Γ ` a ∈ (x : A ∩ B[x]) type, dependent intersection x:A∩B[x]. This type contains all elements a from A such that a is also in B[a]. Γ ` a=a0∈A Γ ` a=a0∈B[a]Γ ` x:A ∩ B[x] Type Γ ` a = a0 ∈ (x : A ∩ B[x]) Remark 6 Do not confuse the dependentT intersection with the intersection of a family of types x:A B[x]. The latter refers to an intersection of types B[x] for all x in A. The Γ; u :(x : A ∩ B[x]); ∆; x : A; y : B[x] ` C[x, y] difference between these two type constructors is similar to the difference between dependent products x:A × B[x] = Γ; u :(x : A ∩ B[x]); ∆ ` C[u, u] Σx:AB[x] and the product of a family of types Πx:AB[x] = x : A → B[x]. Table 1. Rules for dependent intersection Example 7 The ordinary binary intersection is just a spe- cial case of a dependent intersection with a constant second argument: A ∩ B = x : A ∩ B. The Extension of the Semantics We introduce a new term constructor for dependent intersection x : A ∩ B[x]. Example 8 Let A = Z and B[x] = [0 .. x2−5]. Then 2 This constructor bounds the variable x in B[x]. We extend x : A∩B[x] is a set of all integers, such that 0 ≤ x ≤ x −5. the semantics of [2] as follows. Two elements a and a0 are equal in the dependent inter- • The expression x : A ∩ B[x] is a well-formed type if section x:A ∩ B[x] when they are equal both in A and B[a]. and only if A is a type and B[x] is a functional type Example 9 Let A be {0} → N and B[f] be over x : A. That is, for any x from A the expression {1} → [0 .. f(0)], where {0} and {1} are types that B[x] should be a type and if x = x0 ∈ A then B[x] = contain only one element (0 and 1 respectively). Then B[x0]. x:A ∩ B[x] is a type of functions f that map 0 to a natural • The elements of the well-formed type x : A ∩ B[x] are number n0 and map 1 to a natural number n1 ∈ [0 .. n0]. Two such functions f and f 0 are equal in this type, when such terms a that a is an element of both types A and first, f = f 0 ∈ {0} → N, i.e. f(0) = f 0(0), and second, B[a]. f = f 0 ∈ {1} → [0 ..f(0)], i.e. f(1) = f 0(1) ≤ f(0). • Two elements a and a0 are equal in the well-formed 0 0 2.1 Semantics type x : A ∩ B[x] iff a = a ∈ A and a = a ∈ B[a]. • Two types x : A ∩ B[x] and x : A0 ∩ B0[x] are equal We are going to give the formal semantics for dependent when A and A0 are equal types and for all x and y from intersection types based on the predicative PER semantics A if x = y ∈ A then B[x] = B0[y]. for the NuPRL type theory [1, 2]. In the PER semantics types are interpreted as partial equivalence relations (PERs) over terms. Partial equivalence relations are relations that 2.2 The Inference Rules transitive and symmetric, but not necessary reflexive. According to [2], to give the semantics for a type ex- The corresponding inference rules are shown in Table 1. pression A we need to determine when this expression is a well-formed type, define elements of this type, and spec- Theorem 10 All rules of Table 1 are valid in the semantics ify the partial equivalence relation on terms for this type given above. (a = b ∈ A). We should also give an equivalence relation on types, i.e. determine when two types are equal. See [2] This theorem is proved by straightforward application of for details. the semantics definition.

3 Theorem 11 The following rules can be derived from the The main difference between record types and products primitive rules of Table 1 in a type theory with the appro- A1 ×· · ·×An is the that record type has the subtyping prop- priate cut rule. erty. Given two records R1 and R2, if any label declared in R1 as a field of type A is also declared in R2 as a field of Γ ` a = a0 ∈ (x : A ∩ B[x]) type B, such that B ⊆ A, then R2 is subtype of R1. In Γ ` a = a0 ∈ A particular, Γ ` a = a0 ∈ (x : A ∩ B[x]) {x : A ; ... ; x : A } ⊆ {x : A ; ... ; x : A } (3) Γ ` a = a0 ∈ B[a] 1 1 n n 1 1 m m Theorem 12 Dependent intersection is associative, i.e. where m < n. x : A ∩ (y : B[x] ∩ C[x, y]) =e z :(x : A ∩ B[x]) ∩ C[z, z] Example 13 Let P oint = {x : Z; y : Z} and ColorP oint = {x : Z; y : Z; color : Color}. Then The formal proof is checked by the MetaPRL system. the record {x = 0; y = 0; color = red} is not only We show here a sketch of a proof. An element x has a ColorP oint, but it is also a P oint, so we can use type a : A ∩ (b : B[a] ∩ C[a, b]) iff it has types A and this record whenever P oint is expected. For example, b : B[x] ∩ C[x, b]. The latter is a case iff x ∈ B[x] and x ∈ we can use it as an argument of the function of the type C[x, x]. On the other hand, x has type ab :(a : A ∩ B[a])∩ P oint → T . Further the result of this function does not C[ab, ab] iff x ∈ (a : A ∩ B[a]) and x ∈ C[x, x]. The depend whether we use {x = 0; y = 0; color = red} former means that x ∈ A and x ∈ B[x]. Therefore or {x = 0; y = 0; color = green}. That is, these two x ∈ a : A ∩ (b : B[a] ∩ C[a, b]) iff x ∈ A and x ∈ B[x] records are equal as elements of the type P oint, i.e. and x ∈ C[x, x] iff x ∈ ab :(a : A ∩ B[a]) ∩ C[ab, ab]. {x = 0; y = 0; color = red} = 3 Records {x = 0; y = 0; color = green} ∈ {x : Z; y : Z} Using subtyping one can model the private fields. Con- We are going to define record types using dependent in- sider a record r that has one “private” field x of the type tersection. In this section we informally describe what prop- A and one “public” field y of the type B. This record has erties we are expecting from records. The formal definitions the type {x : A; y : B} Using subtyping property we can are presented in Section 4. conclude that it also has type {y : B}. Now we can con- sider type {y : B} as a public interface for this record. A 3.1 Plain Records user knows only that r ∈ {y : B}. Therefore he has ac- cess to field y, but access to field x would be type invalid Records are collection of labeled fields. We use the fol- (i.e. untyped). Formally it meant that a function of the type lowing notations for records: {y : B} → T can assess only the field y on its argument (al- though an argument of this function can have other fields). {x = a ; ... ; x = a } (1) 1 1 n n Further, records do not depend on field ordering. For where x1,..., xn are labels and a1, . . . an are correspond- example, {x = 0; y = 1} should be equal to {y = 1; x = ing fields. Usually labels have a string type, but generally 0}, moreover {x : A; y : B} and {y : B; x : A} should speaking labels can be of any fixed type Label with a de- define the same type. cidable equality. We will use the true type font for labels. The selection operator r.x is used to access record fields. 3.1.1 Records as Dependent Functions If r is a record then r.x is a field of this record labeled x. That is we expect the following reduction rule: Records may be considered as mappings from labels to the corresponding fields. Therefore it is natural to define a {x1 = a1; ... ; xn = an}.xi −→ ai. record type as a with the domain Label (cf. [5]). Since the types of each field may vary, one should Fields may have different types. If each ai has type Ai use dependent function type (i.e., Π type). Let F ield[l] be a then the whole record (1) has the type type of a field labeled l. For example, for the record type (2) take {x1 : A1; ... ; xn : An}. (2) ∆ if then else Also we want the natural typing rule for the field selec- F ield[l] = l = x1 A1 tion: for any record r of the type (2) we should be able to ... conclude that r.xi ∈ Ai. if l = xn then An else Top

4 Then define the record type as the dependent function type:1 e.g., they do not recognize the expression {x : A; x : B} as a valid type. On the other hand, in [11] in the case when

∆ labels coincide the last field overlap the previous ones, e.g., {x1 : A1; ... ; xn : An} = l : Label → F ield[l]. (4) {x : A; x : B} is equal to {x : B}. In both these cases many typing rules of the record calculus need some addi- Now records may be defined as functions: tional conditions that prohibits coincident labels. For ex- ∆ ample, the subtyping relation (3) would be true only when {x1 = a1; ... ; xn = an} = all labels xi are distinct. λl.if l = x then a else 1 1 (5) We will follow the definition (7) and allow repeated la- ... bels and assume that

if l = xn then an {x : A; x : B} = {x : A ∩ B}. (9) And selection is defined as application: This may look unusual, but this notation significantly sim- plifies the rules of the record calculus, because we do not r.l =∆ r l (6) need to worry about coincident labels. Moreover, this al- low us to have multiply inheriting (see Section 4.3.2 for an One can see that these definitions meet the expecting example). Note that the equation (9) holds also in [7]. properties mentioned above including subtyping property. 3.2 Dependent Records 3.1.2 Records as Intersections We want to be able to represent abstract data types and Using the above definitions we can prove that in case when algebraic structures as records. For example, a semigroup all xi’s are distinct labels may be considered as a record with the fields car (repre- senting a carrier) and product (representing a binary op- {x1 : A1; ... ; xn : An} =e {x1 : A1} ∩ ... ∩ {xn : An}. eration). The type of car is the universe U. The type of (7) product should be car × car → car. The problem is This property provides us a simpler way to define records. that the type of product depends on the value of the field First, let us define the type of records with only one field. car. Therefore we cannot use plain record types to repre- We define it as a function type like we did it in the last sec- sent such structures. tion, but for single-field records we do not need dependent We need dependent records [4, 11, 19]. In general a de- functions, so we may simplify the definition: pendent record type has the following form {x : A} =∆ {x} → A (8) {x : A; y : B[x]; z : C[x, y]; ... } (10) where {x} is the singleton subset of type Label. Now we That is, the type of a field in such records can depend on the may take (7) and (8) as a definition of an arbitrary record values of the previous fields. type instead of (4) and keep definitions (5) and (6). This The following main property show the intended meaning way was used in [21] where {x : A} was a primitive type. of this type. The record {x = a; y = b; z = c; ... } has Example 14 The record {x = 1; y = 2} by definition (5) is type (10) if and only if a function that maps x to 1 and y to 2. Therefore it has type {x} → Z = {x : Z} and also has type {y} → Z = {y : Z}. a ∈ A, b ∈ B[a], c ∈ C[a, b],... Hence it has type {x : Z; y : Z} = {x : Z} ∩ {y : Z}. Example 15 Let SemigroupSig be the record type that One can see that when all labels are distinct definitions represents the signature of semigroups: (4) and (7)+(8) are equivalent. That is, for any record ex- SemigroupSig =∆ {car : U; product : car×car → car}. pression {x1 : A1; ... ; xn : An} where xi 6= xj, these two definitions define two extensionally equal types. Semigroups are elements of SemigroupSig However, definitions (7)+(8) differ from the traditional satisfying the associative axiom. This ax- ones, in the case when labels coincide. Most record calculi iom may be represented as an additional field: prohibit repeating labels in the declaration of record types, Semigroup =∆ {car : U; Q 1 We use the standard NuPRL’s notations x : A → B[x] = B[x] product : car × car → car; x:A axm : ∀x, y, z : car. (x·y)·z = x·(y·z)} for the type of functions that maps each x ∈ A to an element of the type B[x]. where x · y stands for product(x, y).

5 3.2.1 Dependent Records as Very Dependent Func- This definition of the SemigroupSig type is extension- tions ally equal to (12), but it has two advantages. First, it is much simpler. Second, dependent intersection allows us to extend We cannot define dependent record type using the ordinary the SemigroupSig type to the Semigroup type by adding dependent function type, because the type of the fields de- an extra field axm: pends not only on labels, but also on values of other fields. To represent dependent records Hickey [11] introduced Semigroup =∆ self : SemigroupSig ∩ the very dependent function type constructor: {axm : ∀x, y, z : self .car (x · y) · z = x · (y · z)} {f | x : A → B[f, x]} (11) where x · y stands for self .product(x, y). Here A is the domain of the function type and the range We can define a dependent record type of an arbitrary B[f, x] can depend on the argument x and the function f length in this fashion as a dependent intersection of single- itself. That is, type (11) refers to the type of all functions g field records associated to the left. with the domain A and the range B[g, a] on any argument Note that Semigroup can be also defined as an intersec- a ∈ A. tion associated to the right: Semigroup = For instance, SemigroupSig can be represented as a very dependent function type ¡rc : {car : U} ∩ rp : {product : rc.car × rc.car → rc.car} ∩ ∆ ¢ SemigroupSig = {r | l : Label → F ield[r, l]} (12) {axm : ∀x, y, z : rc.car (x · y) · z = x · (y · z)}

∆ where F ield[r, l] = where x · y stands for rp.product(x, y). Here rc and rp are bound variables. Both of them refer to the record itself, but if l = car then U else rc has type {car : U} and rp has type {product : ... }. if l = product then r.car × r.car → r.car These two definitions are equal, because of associativity of else Top dependent intersection (Theorem 12). Note that Pollack [19] considered two types of depen- Not every very dependent function type has a meaning. dent records: left associating records and right associating For example the range of the function on argument a cannot records. However, in our framework left and right associa- depend on f(a) itself. For instance, the expression tion are just two different ways of building the same type. {f | x : A → f(x)} We will allow using both of them. Which one to chose is the matter of taste. is not a well-formed type. The type (11) is well-formed if there is some well- 4 The Record Calculus founded order < on the domain A, and the range type B[x, f] on x = a depends only on values f(b), where b < a. The requirement of well-founded order makes the 4.1 The Formal Definitions definition of very-dependent functions to be very complex. See [11] for more details. Now we are going to give the formal definitions of records using dependent intersection. 3.2.2 Dependent Records as Dependent Intersection 4.1.1 Records By using dependent intersection we can avoid the complex concept of very dependent functions. For example, we may Elements of record types are defined as functions from la- define bels to the corresponding fields. We need three primitive operations: SemigroupSig =∆ self : {car : U} ∩ ∆ {product : self .car × self .car → self .car} 1. Empty record: {} = λl.l (We could pick any function as a definition of an empty Here self is a bound variable that is used to refer to the record.) record itself considered as a record of the type {car : U}. This definition can be read as following: 2. Field update/extension: r has type SemigroupSig, when first, r is a ∆ if then else record with a field car of the type U, and sec- r.(x := a) = (λl. l = x a r l) ond, r is a record with a field product of the type r.car × r.car → r.car. 3. Field selection: r.x =∆ r x

6 Reduction rules (r.x := a).x −→ a (r.y := b).x −→ r.x when x 6= y

Single-field record Γ ` A Type Γ ` x ∈ Label Γ ` a ∈ A Γ ` x ∈ Label Γ ` r ∈ {x : A} Γ ` x 6= y ∈ Label Γ ` r ∈ {x : A} Γ ` {x : A} Type Γ ` r.x := a ∈ {x : A} Γ ` (r.y := b) = r ∈ {x : A} Γ ` r.x ∈ A Independent record Γ ` R1 Type Γ ` R2 Type Γ ` r ∈ R1 Γ ` r ∈ R2 Γ ` r ∈ {R1; R2} Γ ` {R1; R2} Type Γ ` r ∈ {R1; R2} Γ ` r ∈ R1 Γ ` r ∈ R2 Left associating record Right associating record Γ ` R1 Type Γ; self : R1 ` R2[self ] Type Γ ` {x : A} Type Γ; x : A ` R[x] Type Γ ` {R1; R2[self ]} Type Γ ` {x : x : A; R[x]} Type

Γ ` r ∈ R1 Γ ` r ∈ R2[r]Γ ` {R1; R2[self ]} Type Γ ` r ∈ {x:A} Γ ` r ∈ R[r.x]Γ ` {x:x:A; R[x]} Type Γ ` r ∈ {R1; R2[self ]} Γ ` r ∈ {x:x:A; R[x]}

Γ ` r ∈ {R1; R2[self ]} Γ ` r ∈ {x : x : A; R[x]} Γ ` r ∈ R1 Γ ` r ∈ R2[r] Γ ` r.x ∈ A Γ ` r ∈ R[r.x]

Table 2. Inference rules for records

We can construct any record by these operations: we de- x for self .x, when such notation does not lead to misunder- fine {x1 = a1; ... ; xn = an} as standing. We assume that this concatenation is a left asso- ciative operation and we will omit inner braces. For exam- ple, we will write {x : A;y : B[self ];z : C[self ]} instead of {}.(x1 := a1).(x2 := a2).....(xn := an) {{{x : A}; {y : B[self ]}}; {z : C[self ]}}. Note that in this expression there are two distinct bound variable self . First 4.1.2 Record Types one is bound in B and refers to the record itself as a record of the type {x : A}. Second self is bound in C, it also refers Single-field record type is defined as to the same record, but it has type {x : A; y : B[self ]}. {x : A} =∆ {x} → A Right associating dependent concatenation. The above where {x} =∆ {l : Label | l = x ∈ Label} is a singleton definitions are enough to form any record type, but to com- set. plete the picture we give the definition of right associating record constructor:

Independent concatenation of record types is defined as ∆ {x : x : A; R[x]} = self : {x : A} ∩ R[self .x] ∆ {R1; R2} = R1 ∩ R2 Syntactical Remarks Here x is a variable bound in R This definition is a partial case of the bellow definition of that represents a field x. Note that we may α-convert the left associating records when R2 does not depend on self . variable x, but not a label x, e.g., {x : x : A; R[x]} = {y : x : A; R[y]}, but {x : x : A; R[x]} 6= {y : y : Left associating dependent concatenation of record A; R[y]}. We will usually use the same name for labels types is defined as and corresponding bound variables. This connection is right associative, e.g., {x : x : A; y : y : B[x]; z : C[x, y]} stands ∆ {self : R1; R2[self ]} = self : R1 ∩ R2[self ] for {x : x : A; {y : y : B[x]; {z : C[x, y]}}}.

Syntactical Remarks Here variable self is bounded in 4.2 The Rules R2. When we use the name “self” for this variable, we can use the shortening {R1; R2[self ]} for this type. Further, we The basic rules of our record calculus are shown in Ta- will omit “self .” in the body of R2, e.g. we will write just ble 2.

7 Theorem 16 All the rules of Table 2 are derivable from the We can define Semigroup by extending definitions given above. SemigroupSig:

From the reduction rules we get: {SemigroupSig; axm : ∀x, y, z : car (x·y)·z = x·(y·z)}

{x1 = a1; ... ; xn = an}.xi −→ ai or as a right associating record: when all xi’s are distinct. We do not show the equality rules here, because in fact, {car : car : U; these rules repeat rules in Table 2 and can be derived from product : product : car × car → car; them using substitution rules in the NuPRL type theory. For example, we can prove the following rules axm : ∀x, y, z : car (x · y) · z = x · (y · z)} Γ ` a = a0 ∈ A Γ ` x = x0 ∈ Label Γ ` (r.x := a) = (r0.x0 := a0) ∈ {x : A} In the first case x · y stands for self .product(x, y) and in 0 0 the second case for just product(x, y). Γ ` r = r ∈ R1 Γ ` r = r ∈ R2 0 Γ ` r = r ∈ {R1; R2} 4.3.2 Multiply Inheriting Example In particular, we can prove that A monoid is a semigroup with a unit. So, {x = 0; y = 0; color = red} = {x = 0; y = 0; color = green} ∈ {x : Z; y : Z} ∆ MonoidSig = {SemigroupSig; unit : car} We can also derive the following subtyping properties: A monoid is an element of MonoidSig which satisfies the {R1; R2} ⊆ R1 axiom of semigroups and an additional property of the unit. {R1; R2} ⊆ R2 That is, Monoid inherits fields from both MonoidSig and {R1; R2[self ]} ⊆ R1 Semigroup. We can define the Monoid type as follows: {x : x : A; R[x]} ⊆ {x : A} Monoid =∆ {{ MonoidSig; Semigroup; 0 0 unit axm : ∀x : car x · unit = x} ` R1 ⊆ R1 self : R1 ` R2[self ] ⊆ R2[self ] 0 0 ` {R1; R2[self ]} ⊆ {R1; R2[self ]} Note, that since MonoidSig and Semigroup shared the ` A ⊆ A0 x : A ` R[x] ⊆ R0[x] fields car and product, these two fields present in the def- ` {x : x : A; R[x]} ⊆ {x : x : A0; R0[x]} inition of Monoid twice. This does not create problems, since we allow repeating labels (Section 3.1.2). Further, we can establish two facts that states the equality Now we have the following subtyping relations: of left and right associating records. {x : x : A; R[x]} =e {x : A; R[self .x]} SemigroupSig ⊃ MonoidSig

{R1; {x : x : A[self ]; R2[self , x]}} =e ∪ ∪ {{R1; x : A[self ]}; R2[self , self .x]} Semigroup ⊃ Monoid For example, using these two equalities we can prove that 4.3.3 Abstract {x : A; y : B[self .x]; z : C[self .x; self .y]} =e {x : x : A; y : y : B[x]; z : C[x; y]} We can also represent abstract data types as dependent records. Consider for example a collection 4.3 Examples of element of type A. This data structure consists of an ab- stract type car for collections of elements of the type A, a 4.3.1 Semigroup Example constant of this type empty to construct an empty collec- tion, and functions member s a to inquire if element a is in Now we can define the SemigroupSig type in two ways: collection s, and insert s a to add element a into collec- tion s. These functions should satisfy certain properties that {car : U; product : car × car → car} or guarantee their intended behavior: {car : car : U; product : car × car → car} 1. The empty collection does not have elements. Note that in the first definition car in the declaration of product stands for self .car, and in the second definition 2. insert s a has all element that s has and element a car is just a bound variable. and nothing more.

8 A formal definition of the data structure of collections could Remark In is interesting to note that in the presence of be written as a record: Markov’s principle [14] there is an alternative way to define [P ]:

∆ ∆ Collection(A) = [P ] = ((P ≡> Void) ≡> Void) {car : U; T where A ≡> B =∆ B. We will not give any details here, since empty : car; x:A member : car → A → Boolean; it is beyond the scope of the paper. insert : car → A → car; We can also define sets without T op and squash type. emp axm : ∀a : A a∈ / empty First, define independent sets:

ins axm : ∀s : car ∀a, b : A (member (insert s a) b) ∆ [ ⇐⇒ (member s b) ∨ (a = b ∈ A)} {A|B} = A. x:B 5 Sets and Dependent Intersections Then define set type:

∆ Set type constructor allows us to hide a part of a witness. {x : A|B[x]} = x : A ∩ {A|B[x]}.

The Mystery of Notations It is very surprising that Example 17 Instead of defining Semigroup type as an braces {... } were used for sets and for records indepen- extension of SemigroupSig type with an additional field dently for a long time. But now it turns out that sets and axm, we could define the Semigroup type as a subset of records are almost the same thing, namely, dependent inter- SemigroupSig: section! Compare the definitions for sets and records: Semigroup =∆ {S : SemigroupSig |∀x, y, z : S.car ... } {x : T | P [x]} =∆ x : T ∩ [P [x]] Now we will show that the set type constructor (which is ∆ {self : R1; R2[self ]} = self : R1 ∩ R2[self ] primitive in NuPRL) may be defined as a dependent inter- section as well. The only differences between them are that we use squash in First, we assume that our type theory has the T op type, the first definition and write “|” for sets and “;” for records. that is a supertype of any other type. We will need only one So, we will use the following definitions for records: ∆ property of the T op type: T∩ T op = T for any type T . (In {self : R1 | R2[self ]} = {self : R1; [R2[self ]]} = NuPRL T op is defined as x:V oid V oid, where V oid is the self : R1 ∩ [R2[self ]] empty type). {x : x : A | R[x]} =∆ {x : x : A; [R[x]]} = Now consider the following type (squash operator): self : {x : A} ∩ [R[self .x]] ∆ This gives us the right to use the shortening notations [P ] = {x : Top | P } as in Section 4.1.2 to omit inner braces and “self ”. For [P ] is an empty type when P is false, and is equal to T op example, we can rewrite the definition of the Semigroup when P is true. type as

Theorem 18 Semigroup =∆ {car : U;

{x : T | P [x]} =e x : T ∩ [P [x]] (13) product : car × car → car | We can not take (13) as a definition of sets yet, because ∀x, y, z : car (x · y) · z = x · (y · z)} we defined squash operator as a set. But actually the squash operator is defined in MetaPRL’s version of the NuPRL Remark Note that we cannot define dependent intersec- type theory as a primitive constructor and rules for the set tion as a set: type depend on the squash operator. (See [17] for the rules ∆ x : A ∩ B[x] = {x : A | x ∈ B[x]}. (wrong!) for the squash type and explanations why this is a primitive type). Thus, we can take (13) as a definition. First of all, this set is not well-formed in the NuPRL type Moreover, the squash operator could be defined using theory (this set would be a well-formed type, only when x ∈ other primitives. For example, one can define the squash B[x] is a type for all x ∈ A, but the membership is a well- type using union: formed type in the NuPRL type theory, only when it is true).

∆ [ Second, this set type does not have the expected equivalence [P ] = Top. relation. Two elements are equal in this set type, when they x:P are equal just in A, but to be equal in the intersection they (Union is a type that dual to intersection [18, 12]). must be equal in both types A and B (see Example 1).

9 Acknowledgments I am grateful to Robert Constable, [11] Jason J. Hickey. Formal objects in type theory us- Aleksey Nogin and anonymous referees for their comments. ing very dependent types. In Foundations of Object Oriented Languages 3, 1996. Available electronically References through the FOOL 3 home page. [12] Jason J. Hickey. The MetaPRL Logical Programming [1] Stuart F. Allen. A Non-type-theoretic Definition of Environment. PhD thesis, Cornell University, Ithaca, Martin-Lof’s¨ Types. In D. Gries, editor, Proceedings NY, January 2001. of the 2nd IEEE Symposium on Logic in Computer Sci- ence, pages 215–224. IEEE Computer Society Press, [13] Jason J. Hickey, Aleksey Nogin, Alexei Kopylov, et al. June 1987. MetaPRL home page. http://metaprl.org/. [14] Alexei Kopylov and Aleksey Nogin. Markov’s princi- [2] Stuart F. Allen. A Non-Type-Theoretic Semantics for ple for propositional type theory. In L. Fribourg, edi- Type-Theoretic Language. PhD thesis, Cornell Uni- tor, Computer Science Logic, Proceedings of the 10th versity, 1987. Annual Conference of the EACSL, volume 2142 of [3] Lennart Augustsson. Cayenne — a language with de- Lecture Notes in Computer Science, pages 570–584. pendent types. In International Conference on Func- Springer-Verlag, 2001. tional Programming, pages 239–250, 1998. [15] Xavier Leroy. Manifest types, modules, and sepa- [4] Gustavo Betarte and Alvaro Tasistro. Extension of rate compilation. In Proceedings of the 21st ACM Martin-Lof’s¨ type theory with record types and sub- SIGPLAN-SIGACT symposium on Principles of pro- typing. In Giovanni Sambin and Jan M. Smith, edi- gramming languages, pages 109–122. ACM Press, tors, Twenty-Five Years of Constructive Type Theory, 1994. volume 36 of Oxford Logic Guides, pages 21–39, Ox- [16] Per Martin-Lof.¨ Intuitionistic Type Theory, Studies ford, 1998. Clarendon Press. in Proof Theory, Lecture Notes. Bibliopolis, Napoli, [5] Robert L. Constable. Types in logic, mathematics 1984. and programming. In Sam Buss, editor, Handbook of [17] Aleksey Nogin. Quotient types: A modular approach. Proof Theory, chapter 10. Elsevier Science, 1997. In Victor A. Carreno,˜ Cezar´ A. Munoz,˜ and Sophiene` th [6] Robert L. Constable et al. Implementing Mathematics Tahar, editors, Proceedings of the 15 International with the NuPRL Development System. Prentice-Hall, Conference on Theorem Proving in Higher Order Log- NJ, 1986. ics (TPHOLs 2002), volume 2410 of Lecture Notes in Computer Science, pages 263–280. Springer-Verlag, [7] Robert L. Constable and Jason Hickey. NuPRL’s class 2002. theory and its applications. In Friedrich L. Bauer and Ralf Steinbrueggen, editors, Foundations of Se- [18] Benjamin C. Pierce. Programming with intersection cure Computation, NATO ASI Series, Series F: Com- types, union types, and polymorphism. Technical Re- puter & System Sciences, pages 91–116. IOS Press, port CMU-CS-91-106, Carnegie Mellon University, 2000. February 1991. [19] Robert Pollack. Dependently typed records for rep- [8] Mario Coppo and Mariangiola Dezani-Ciancaglini. resenting mathematical structure. In J. Harrison and An extension of the basic functionality theory for the M. Aagaard, editors, Theorem Proving in Higher Or- λ-calculus. Notre-Dame Journal of Formal Logic, der Logics: 13th International Conference, TPHOLs 21(4):685–693, October 1980. 2000, volume 1869 of Lecture Notes in Computer Sci- [9] Judicael¨ Courant. An applicative module calculus. ence, pages 461–478. Springer-Verlag, 2000. In TAPSOFT, Lectures Notes in Computer Science, [20] Garrel Pottinger. A type assignment for the strongly pages 622–636, Lille, France, April 1997. Springer- normalizable λ-terms. In Jonathan P. Seldin and Verlag. J. Roger Hindley, editors, To H. B. Curry: Essays [10] Robert Harper and Mark Lillibridge. A type- in Combinatory Logic, Lambda Calculus and Formal- theoretic approach to higher-order modules with shar- ism, pages 561–577. Academic Press, London, 1980. ing. In Conference record of POPL ’94: 21st ACM [21] John C. Reynolds. Design of the programming lan- SIGPLAN-SIGACT Symposium on Principles of Pro- guage forsythe. Technical Report CMU-CS-96-146, gramming Languages, pages 123–137, Portland, OR, Carnegie Mellon University, June 1996. January 1994.

10