We argue that the novel combination of type classes and existential types in a single language yields significant expressive power. We explore this combination in the context of higher-order functional languages with static typing, parametric polymorphism, algebraic data types, and Hindley-Milner type inference. Adding existential types to an existing functional language that already features type classes requires only a minor syntactic extension. We first demonstrate how to provide existential quantification over type classes by extending the syntax of algebraic data type definitions and give examples of possible uses. We then develop a type system and a type inference algorithm for the resulting language. Finally, we present a formal semantics by translation to an implicitly-typed second-order l-calculus and show that the type system is semantically sound. Our extension has been implemented in the Chalmers Haskell B. system, and all examples from this paper have been developed using ...

This paper demonstrates that the novel combination of type classes and existential types adds significant expressive power to a language, requiring only a minor syntactic change. We explore this combination in the context of higher-order functional languages with static typing, parametric polymorphism, algebraic data types, and Hindley-Milner type inference. Since we have examined the underlying type-theoretic issues already, this paper focuses on the practical aspects of our extension. We first examine limitations of existing functional and object-oriented languages. We then give examples to demonstrate how our first-class abstract types with user-defined interfaces address those limitations. Finally, we give an informal description of the translation from our language to a target language without type classes. Our extension equally applies to other languages with similar type systems and is independent of strictness considerations. It has been implemented in the Chalmers Haskell B. s...

Abstract not found

Since record polymorphism is one of essential factors for object-oriented languages, various approaches to incorporate record polymorphism into type systems have been proposed to lay the foundation for object-oriented languages. Recursive types, which are essentially types of lists or trees, are major programming tools. In object-oriented languages, a pseudo variable "self" has a recursive type, which requires that type systems be able to treat recursive types. The purpose of this paper is to provide a type system and its type inference algorithm which can handle subtyping, recursive types and parametric polymorphism without any kind of type declaration or unnatural restrictions. We prove soundness and completeness of the type inference algorithm. Our system integrates subtyping and recursive types into Damas and Milner's type system and preserves important properties such as existence of principal typing. The basic idea is that we consider a type as a regular tree.

The concepts of the basic entities, i.e., objects, object classes, object types, etc., in the type hierarchy of object-oriented languages are revisited. The notion of object reuse is defined and elaborated. We show that while object classes are useful in object description and creation, the class-is-type principle which is used in many object-oriented languages is inadequate for object reuse. We also show that parameterized types and generic functions are better served by using kind-bounded qualification than universal qualification and other mechanisms. Keywords: Object reuse, software integration, objects, classes, types, kinds, class-is-type principle, parameterized types, generic functions, kind-bounded polymorphism 1

There exist some preprocessing based language extensions for database management where persistence is orthogonal to the class hierarchy. They allow a class hierarchy to be built from both database classes and non-database classes together. Such a property is important in that classes can be reused in implementing database classes, and vice versa. In this paper, we elaborate on the orthogonality of persistence to class-hierarchies, and find that the existing method to achieve this is not satisfactory because of the side-effects of the heterogeneosity of the links in a class hierarchy; some links represent subset(IsA) relationships between database classes, while the others denote inheritance for code-reuse. Finally, we propose LOD*, a C++ extension to database access, which separates the different categories of links into independent hierarchies, and supports orthogonal persistence to the class hierarchy, overcoming the limitations in the previous methods.

"The high cost of building large software systems can be attributed to the fact that most software development efforts are done from scratch" ([Mic88], p. 27). Common program elements like stacks and sorting functions are rewritten for each new project. Therefore, one obvious way to reduce development costs is to, wherever possible, reuse previously written code. In this way, new software systems are built rather than written. With the introduction of concepts like data abstraction, encapsulation, inheritance, and polymorphism, object-oriented programming languages make it easier to include previously written code in new projects. C++ is one of the most popular object-oriented programming languages [KA90]. It provides constructs for data abstraction, encapsulation, inheritance, and polymorphism. Parametric polymorphism in C++ is achieved through the use of function or class templates. The purpose of this thesis is to show that while C++ templates provide polymorphism they do not encou...

C++ uses `class' as the basis of `subtypepolymorphism ' and `inheritance', but it has been pointed out that the overloading of `class' limits the expressiveness and makes its type system inflexible. This made C++ and some other object-oriented languages to separate a class into two modules -- an interface and an implementation. But, there seems to be no leading C++ model for separating interface lattice from implementation lattice. Moreover none of proposed models describe the result of the separation in a formal way. As a result it is hard to understand what the type space would be like after the separation. This paper 1 presents a formal model for the separation of interface and implementation in C++, which explains the properties of the resulting type space after the separation. 1 Introduction C++ uses `public', `private' or `protected' to control access to members or member functions of a class. When a member or a member function of a class is specified as public, its name is...