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...

this document we would like to propose some relatively minor additions to Java's syntax and semantics [GJS96] in order to increase the expressiveness of the language with little cost in semantic complexity. We avoided making suggestions that would invalidate or change the semantics of programs written in the current version of Java. While the main point of the language extensions are to support parametric polymorphism, we also added features which provide better support for binary methods, a kind of method that is often difficult to support in a statically typed language. (See [BCC