PolyTOIL is a new statically-typed polymorphic object-oriented programming language that is provably type-safe. By separating the de nitions of subtyping and inheritance, providing a name for the type of self, and carefully de ning the type-checking rules, we have obtained a language that is very expressive while supporting modular type-checking of classes. The matching relation on types, which is related to F-bounded quanti cation, is used both in stating type-checking rules and expressing the bounds on type parameters for polymorphism. The design of PolyTOIL is based on a careful formal de nition of type-checking rules and semantics.

We present the design and rationale of a new statically-typed object-oriented language, LOOM. LOOM retains most of the features of the earlier language PolyTOIL. However the subtyping relation is dropped from LOOM in favor of the matching relation. "Hash types", which are defined in terms of matching, are introduced to provide some of the bene ts of subtyping. These types can be used to provide support for heterogeneous data stuctures in LOOM. LOOM is considerably simpler than PolyTOIL, yet is just as expressive. The type system for the language is decidable and provably type safe. The addition of modules to the language provides better control over information hiding and allows the provision of access like that of C++'s friends.

. We present the design and rationale of a new statically-typed object-oriented language, LOOM. LOOM retains most of the features of the earlier language PolyTOIL. However the subtyping relation is dropped from LOOM in favor of the matching relation. "Hash types", which are defined in terms of matching, are introduced to provide some of the benefits of subtyping. These types can be used to provide support for heterogeneous data stuctures in LOOM. LOOM is considerably simpler than PolyTOIL, yet is just as expressive. The type system for the language is decidable and provably type safe. The addition of modules to the language provides better control over information hiding and allows the provision of access like that of C++'s friends. 1 Introduction Most statically-typed object-oriented programming languages, including C++ [ES90], Java [AG96], Object Pascal [Tes85], and Modula 3 [CDG + 88], suffer from very rigid type systems which can block the easy expression of programmers ' ideas,...

While simple static-typing disciplines exist for object-oriented languages like C++, Java, and Object Pascal, they are often so inflexible that programmers are forced to use type casts to get around the restrictions. At the other extreme are languages like Beta and Eiffel, which allow more freedom, but require run-time or link-time checking to pick up the type errors that their type systems are unable to detect at compile time. This paper presents a collection of sample programs which illustrate problems with existing type systems, and suggests ways of improving the expressiveness of these systems while retaining static type safety. In particular we will discuss the motivations behind introducing "MyType", "matching", and "match-bounded polymorphism" into these type systems. We also suggest a way of simplifying the resulting type system by replacing subtyping by a type system with a new type construct based on matching. Both systems provide for binary methods, which are often difficult...

e considerations that led to this choice, and we describe LabBase's design and our experiences implementing it. We use our experiences with LabBase to illuminate the advantages and disadvantages of this approach to exploiting persistent technology. We also analyze how ObjectStore's particular characteristics shaped LabBase's design. This work was supported by funds from the U.S. National Institutes of Health, National Center for Human Genome Research, grant number P50 HG00098. y To appear in Sixth International Workshop on Persistent Object Systems. Available as ftp://genome.wi.mit.edu/pub/steve/Y1994/labbase-design.ps.Z. 1 Introduction LabBase is a light-weight domain-specific DBMS implemented on top of the ObjectStore persistent object system [1, 2, 3]. The implementation of LabBase is evidence that constructing a domain-specific DBMS is one workable solution to the problem of "[h]ow to design a

Constructing a light-weight domain-speci c database management system (DBMS) is one way \...to design applications that e ectively exploit...persistent technology". We have implemented a domain-speci c DBMS, LabBase, on top of the ObjectStore persistent object system (which is basically a persistent C++). LabBase is tailored to the application domain of laboratory information systems: it is designed to record experimental steps and results in a high-throughput laboratory production line|for example, one of those operated as part of the Whitehead/MIT Genome Center's genome-mapping projects. Given the task of representing the materials and experimental steps of a laboratory production line in C++, one could take two approaches: 1. Model each laboratory material and experimental step directly as a C++ class. A system constructed in this way can record the operations of a single laboratory production line. 2. Build a layer of abstraction in C++ in the form of a data de nition facility based on general notions of laboratory materials and experimental steps. A system constructed in this way can be adapted to various laboratory production lines by supplying appropriate data de nitions for the laboratory materials and experimental steps particular to speci c production lines. For LabBase we chose the second approach|that of creating a domainspeci c DBMS|in light of our previous experiences working with a system based on the rst approach. We detail the considerations that led to this choice, and we describe LabBase's design and our experiences implementing it. We use our experiences with LabBase to illuminate the advantages and disadvantages of this approach to exploiting persistent technology. We also analyze how ObjectStore's particular characteristics shaped LabBase's design.

Pure object-oriented languages have tended to assume that classes can take the place of modules in programming in the large. We argue that modules are still needed in these languages and present the design of a module construct for our language LOOM which works well with the object-oriented paradigm. We discuss and illustrate the advantages of these modules over a class-only approach. In particular we illustrate the advantages of modules in supporting better control over information hiding, including the support of access like C++'s friends. Research paper: language design 1 Introduction As programmers and language designers have gotten more experience with object-oriented languages, it has become clearer that class boundaries are not always the correct abstraction layer for large programs. Interestingly it is the hybrid languages which have grown from ADT-style languages which have often provided the best support for modularity. Thus Ada 95 [Int95] and Modula-3 [CDG + 88] have int...