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 a simple extension of typed -calculus where functions can be overloaded by putting different "branches of code" together. When the function is applied, the branch to execute is chosen according to a particular selection rule which depends on the type of the argument. The crucial feature of the present approach is that the branch selection depends on the "run-time type" of the argument, which may differ from its compile-time type, because of the existence of a subtyping relation among types. Hence overloading cannot be eliminated by a static analysis of code, but is an essential feature to be dealt with during computation. We obtain in this way a type-dependent calculus, which differs from the various -calculi where types do not play any role during computation. We prove Confluence and a generalized Subject-Reduction theorem for this calculus. We prove Strong Normalization for a "stratified" subcalculus. The definition of this calculus is guided by the understand...

In order to illuminate the fundamental concepts involved in object-oriented programming languages, we describe the design of TOOPL, a paradigmatic, statically-typed, functional, object-oriented programming language which supports classes, objects, methods, hidden instance variables, subtypes, and inheritance. It has proven to be quite difficult to design such a language which has a secure type system. A particular problem with statically type checking object-oriented languages is designing type-checking rules which ensure that methods provided in a superclass will continue to be type correct when inherited in a subclass. The type-checking rules for TOOPL have this feature, enabling library suppliers to provide only the interfaces of classes with actual executable code, while still allowing users to safely create subclasses. In order to achieve greater expressibility while retaining type-safety, we choose to separate the inheritance and subtyping hierarchy in the language. The design of...

Cecil is a new purely object-oriented language intended to support rapid construction of highquality, extensible software. Cecil combines multi-methods with a classless object model, object-based encapsulation, and optional static type checking. Cecil's static type system distinguishes between subtyping and code inheritance, but Cecil enables these two graphs to be described with a single set of declarations, optimizing the common case where the two graphs are parallel. Cecil includes a fairly flexible form of parameterization, including both explicitly parameterized objects, types, and methods and implicitly parameterized methods related to the polymorphic functions commonly found in functional languages. By making type declarations optional, Cecil aims to support mixed exploratory and production programming styles. This document describes the design of the Cecil language as of March, 1993. It mixes the specification of the language with discussions of design issues and explanations of...

Baby Modula-3 is a small, functional, object-oriented programming language. It is intended as a vehicle for explaining the core of Modula-3, from a biased perspective: Baby Modula-3 includes the main features of Modula-3 related to objects, but not much else. To the theoretician, Baby Modula-3 provides a tractable, concrete example of an objectoriented language, and we use it to study the formal semantics of objects. Baby Modula-3 is defined with a structured operational semantics and with a set of static type rules. A denotational semantics guarantees the soundness of this definition. 1 Introduction Baby Modula-3 is a small, functional, object-oriented programming language with a static type system. It is intended as a distillation and an explanation of the core of Modula-3 (Nelson, 1991), from a biased perspective: Baby Modula-3 includes the main features of Modula-3 related to objects, but not much else. To the theoretician, Baby Modula-3 provides a tractable, concrete example of a...

this paper (Compagnoni, Intersection Types and Bounded Polymorphism 3 1994; Compagnoni, 1995) has been used in a type-theoretic model of object-oriented multiple inheritance (Compagnoni & Pierce, 1996). Related calculi combining restricted forms of intersection types with higher-order polymorphism and dependent types have been studied by Pfenning (Pfenning, 1993). Following a more detailed discussion of the pure systems of intersections and bounded quantification (Section 2), we describe, in Section 3, a typed -calculus called F ("Fmeet ") integrating the features of both. Section 4 gives some examples illustrating this system's expressive power. Section 5 presents the main results of the paper: a prooftheoretic analysis of F 's subtyping and typechecking relations leading to algorithms for checking subtyping and for synthesizing minimal types for terms. Section 6 discusses semantic aspects of the calculus, obtaining a simple soundness proof for the typing rules by interpreting types as partial equivalence relations; however, another proof-theoretic result, the nonexistence of least upper bounds for arbitrary pairs of types, implies that typed models may be more difficult to construct. Section 7 offers concluding remarks. 2. Background

. This paper, which is partly tutorial in nature, summarizes some basic research goals in the study and development of typed objectoriented programming languages. These include both immediate repairs to problems with existing languages and the long-term development of more flexible and expressive, yet type-safe, approaches to program organization and design. We summarize and compare three object models used in the theoretical literature. We also consider approaches to a few technical problems, including changes in the type of a method (member function) from super (base) class to sub (derived) class and the use of types that give information about the implementations as well as the interfaces of objects. Such implementation types seem essential for adequate typing of binary operations on objects, for example. 1 Introduction A number of largely "theoretical" research efforts over the last five to ten years have developed and analyzed type systems for model object-oriented languages. Thi...

System F≤ is an extension of second-order typed lambda calculus, where a subtype hierarchy among types is defined, and bounded second-order lambda abstraction is allowed. This language is a basis for much of the current research on integration of typed functional languages with subtypes and inheritance. An algorithm to perform type checking for F≤ expressions has been known since the language Fun was defined. The algorithm has been proved complete, by the author and P.-L. Curien, which means that it is a semi-decision procedure for the type-checking problem. In this paper we show that this algorithm is not a decision procedure, by exhibiting a term which makes it diverge. This result was the basis of Pierce's proof of undecidability of typing for F≤. We study the behavior of the algorithm to show that our diverging judgement is in some sense contained in any judgement which makes the algorithm diverge. On the basis of this result, and of other results in the paper, we claim that the c...

ing RationalFun from Rational yields a higher order type operator that, given a specification, forms the type of objects that satisfy it. Philip Santas DeclareDomain := (Fun: Type-?Category) +? (((Rep: Type) +? with(Rep,Fun(Rep))) SomeRep) The type of Rational objects can now be expressed by applying the DeclareDomain constructor to the specification RationalFun: Rational := DeclareDomain(RationalFun) or the shortcut: Rational : RationalFun In order to give proper treatment to the interaction between representations and subtyping, it is necessary to separate Rational into the specifications of its functions and the operators which capture the common structure of all object types. This separation is also important for the semantical construction of categories and the definition of the internal structures of the types. 2.1. Multiple Representations Rationals are created using the function box, which captures the semantics of dynamic objects in object oriented programming.A rational...

Closure conversion is a critical program transformation for higher-order languages that eliminates lexically nested, first-class functions or procedures. In particular, closure conversion translates each function definition f into a closure -- a data structure consisting of a pointer to closed code and another data structure which represents the environment or context of the function. The code abstracts the arguments of f as well as the free variables of f, and the environment provides the values for the free variables of f. Function application is translated to a sequence which invokes the code of the function's closure on the environment of the closure and the arguments. Since the code is closed and separated from the data which it manipulates, it may be defined...