Subtyping is not a go o d \Match" for ? ob ject-oriented languages 1 1 ?? 2 Kim B. Bruce ,LeafPetersen , and Adrian Fiech 1 Williams College, Williamstown, MA, USA 2 Memorial University of Newfoundland, St. John's, Newfoundland, Canada Abstract. Wepresent the design and rationale of a new statically-typ ed ob ject-oriented language, LO O M. LOOM retains most of the features of the earlier language PolyTOIL. However the subtyping relation is dropp ed from LOOM in favor of the matching relation. \Hash typ es", which are de ned in terms of matching, are intro duced to provide some of the b ene ts of subtyping. These typ es can b e used to provide supp ort for heterogeneous data stuctures in LOOM. LO O M is considerably sim- pler than PolyTOIL,yet is just as expressive. The typ e system for the language is decidable and provably typ e safe. The addition of mo dules to the language provides b etter control over information hiding and allows the provision of access like that of C++'s friends. 1 Intro duction Most statically-typ ed ob ject-oriented programming languages, including C++ + [ES90], Java [AG96], Ob ject Pascal [Tes85], and Mo dula 3 [CDG 88], su er from very rigid typ e systems whichcanblock the easy expression of program- mers' ideas, particularly in the de nition of sub classes. Other statically-typ ed ob ject-oriented languages, such as Ei el [Mey92] and Beta [MMMP90], are more exible, but require run-time or link-time checks in order to eliminate holes in the typ e system. One imp ortantgoalof our previous work in designing static typ e systems for ob ject-oriented languages has b een to design exible, yet safe, static typ e systems (see for example [Bru93, Bru94, BSvG95]). In this pap er we prop ose a fairly radical departure from previous statically-typ ed ob ject-oriented languages by dropping subtyping in favor of a relation called matching and a new typ e constructor related to matching. It has b ecome clear in the last several years that the concepts of inheritance and subtyping in ob ject-oriented languages are not at all the same. (See [Sny86] for early hints, and [CHC90, AvdL90, LP91] for more de nitive treatments of the topic.) In earlier pap ers [Bru93,Bru94, BSvG95], weintro duced the notion of matching, a relation b etween ob ject typ es which is more general than subtyping. ? Bruce and Petersen's researchwas partially supp orted by NSF grant CCR-9424123. Fiech's researchwas partially supp orted by NSERCgrant OGP0170497. ?? Current address: Scho ol of Computer Science, Carnegie-Mellon University, Pitts- burgh, PA, USA A history of matching can b e found in [BSvG95]. See also [AC95] for a discussion of explanations of matching in terms of F-b ounded and higher-order subtyping. An imp ortant feature of matching is that if two classes are sub classes, then the corresp onding ob ject typ es are in the matching relation. However, these typ es are not generally in the subtyp e relation if the language includes a typ e expression, MyType, standing for the typ e of self. Since MyType is extremely valuable, we end up with a mismatchbetween subtyping and inheritance. The language PolyTOIL [BSvG95] supp orts b oth subtyping and matching. It also supp orts b ounded p olymorphism where the b ounds on typ e parameters are given in terms of the matching relation. Unfortunately, the relations of matching and subtyping are similar enough that it might b e dicult for a programmer to keep their di erences straight. As a result we b egan considering the p ossibility of simplifying the language by dropping one or the other. It was clear that matching was absolutely necessary in PolyTOIL in order to express the typ e-checking rules for sub classes, as well as to provide constraints for p olymorphic op erations and data structures. Subtyping was to o restrictive to serve either of these purp oses. Moreover, as welooked at the sample programs we had written in PolyTOIL, we noticed that we rarely used subtyping. In the presence of MyType and match-b ounded p olymorphism, we almost never needed to explicitly change the typ es of metho ds in sub classes. With this in mind, we decided to be bold and investigate the results of eliminating subtyping in favor of matching. While this caused no problems with the inheritance mechanism, we did discover a few situations where we found it dicult to do without subtyping. To deal with this we intro duced a new typ e constructor, #T ,which represents elements whose typ es matchthetyp e T. With this addition, we found that we had a language whichwas essentially as expressiveas PolyTOIL ,yet signi cantly less complex. In the next section we review brie y the main features of PolyTOIL . In section 3 we intro duce the language LOOM. We pay sp ecial attention to the intro duction of a new typ e constructor which can b e applied to ob ject typ es to form typ es whichhave prop erties similar to subtyp es (but are less restrictive). In the following section weprovide a brief overview of the technical results used to justify the use of the language: typ e-checking is decidable and the language is provably typ e-safe. Weprovide a brief overview of LO O M 's mo dule system in section 5. Finally in section 6 we summarize and evaluate the features of the language. 2 Intro duction to PolyTOIL and Matching In [BSvG95]weintro duced PolyTOIL , a statically-typ ed ob ject-oriented pro- gramming language which provides all of the usual constructs of class-based ob ject-oriented languages. In particular, it supp orts ob jects which consist of instance variables and metho ds, and in which computation is based on message- sending. Reuse is supp orted via inheritance, subtyping, and a form of b ounded p olymorphism. We refer the reader to [BSvG95] for the details of the language. Weprovide only a brief summary here. Relatively innovative features of the language include: { The use of MyType in classes to refer to the typ e of self, the receiver of the message. { The treatment of classes as rst-class values of the language. They have typ es and can b e b oth parameters to functions and returned as the results of functions. { The separation of the inheritance and subtyping hierarchies, in order to avoid problems which can arise with so-called binary metho ds. { The intro duction of a new ordering called \matching", written <# , which corresp onds closely to typ e changes allowed in de ning sub classes. Subtyp- ing, written <: , is also supp orted. { Supp ort for a form of b ounded p olymorphism, called match-bounded poly- morphism in which the b ound is expressed in terms of the new matching ordering. Within the scop e of each ob ject (or class), PolyTOIL de nes a typ e identi er MyType that represents the typ e of the ob ject itself. This typ e is \anchored" to the typ e of the ob ject in which it app ears, so that an app earance of MyType in the typ e of a metho d inherited from another class represents the typ e of an instance of the current class, rather than the parent class in which the metho d was de ned. Matching is a relation b etween typ es whichisvery similar to subtyping, but is designed to corresp ond b etter to the inheritance hierarchy of classes and ob jects. An ob ject typ e matches an ob ject typ e in PolyTOIL , if for every metho d m : included in ob ject typ e there is a corresp onding metho d m : included i i i i in ob ject typ e suchthat <: (where o ccurrences of the keyword MyType i i in the metho d typ es are treated as uninterpreted free variables). The de nition of subtyping for ob ject typ es is similar to that for match- 3 ing, but also requires that MyType only o ccur p ositively in metho d typ es (see [BSvG95] for de nitions and details). In particular, an ob ject typ e with a metho d with parameter of typ e MyType cannot haveany non-trivial subtyp es. As a re- sult, if a class has a metho d with a parameter of typ e MyType, then sub classes will not giverisetosubtyp es. While <: implies that any elementoftyp e can b e treated as b eing of typ e , the imp ort of matching is weaker. If <# then any message senttoan ob ject of the typ e could also b e sent to an ob ject of typ e . MyType and matching are crucial to the expressiveness of PolyTOIL . My- Type is often used in expressing the typ es of metho ds whose typ es will need to change in sub classes. It app ears frequently in asso ciation with copy or clone 3 Roughly, an o ccurrence of an identi er is p ositive (or covariant) if it is on the left side of an even numb er of function typ es, and is negative (or contravariant) if it is on the left of an o dd numb er of function typ es. In particular, if the return typ e of a function is MyType, then that o ccurrence of MyType is p ositive. On the other hand, if a parameter typ e of a function is MyType, then that o ccurrence is negative.