A Generic Framework for Genericity

benefits

Generic (polymorphic) type-safe containers are the primary motivation for generics (in Ada, Eiffel, and recently proposed additions to Java and C#) and templates (in C++). We studied buffer classes and found that they could not be unified by type parameters. At times, unification required non-type parameters (e.g., parameters representing operators, keywords or algorithmic details) and at other times -the nature of variations was not parametric which called for a more general unification mechanism. Investigation of the reasons behind the observed symptoms revealed that unification problems were caused by "feature combinations": Other than by type, each class was also affected by yet other features and implementation of various features interacted with classes in rather chaotic ways. In the paper, we show examples of how the feature combination manifests in programs. We believe that we are dealing with a fundamental phenomenon that will cause many other class containers and application programs to suffer from the same problem. In our case study, some of the difficulties were caused by limitations specific to Java generics. Yet others were more fundamental and reflected the weakness of parameterization mechanisms supported by today's programming languages. We suggest that stronger generics systems would considerably enhance capabilities of programming languages in the areas of generic programming, reuse and maintenance. We refer to a meta-level parameterization mechanism that can effectively unify any types of variations triggered by feature combination, and can be applied to any programming language. We discuss the trade-offs between conventional type-parametric generics built-into today's programming languages and the meta-level parameterization approach.

2004

Concepts are an essential language feature for generic programming in the large. Concepts allow for succinct expression of constraints on type parameters of generic algorithms, enable systematic organization of problem domain abstractions, and make generic algorithms easier to use. In this paper we present the design of a type system and semantics for concepts that is suitable for non-typeinferencing languages. Our design shares much in common with the type classes of Haskell, though our primary influence is from best practices in the C ++ community, where concepts are used to document type requirements for templates in generic libraries. Concepts include a novel combination of associated types and sametype constraints that do not appear in type classes, but that are similar to nested types and type sharing in ML.

ArXiv, 2021

We present a generic programming framework for OCAML which makes it possible to implement extensible transformations for a large scale of type definitions. Our framework makes use of objectoriented features of OCAML, utilising late binding to override the default behaviour of generated transformations. The support for polymorphic variant types complements the ability to describe composable data types with the ability to implement composable transformations.

Journal of Functional Programming, 2006

Many modern programming languages support basic generics, sufficient to implement type-safe polymorphic containers. Some languages have moved beyond this basic support, and in doing so have enabled a broader, more powerful form of generic programming. This paper reports on a comprehensive comparison of facilities for generic programming in eight programming languages: C++, Standard ML, Objective Caml, Haskell, Eiffel, Java, C# (with its proposed generics extension), and Cecil. By implementing a substantial example in each of these languages, we illustrate how the basic roles of generic programming can be represented in each language. We also identify eight language properties that support this broader view of generic programming: support for multi-type concepts, multiple constraints on type parameters, convenient associated type access, constraints on associated types, retroactive modeling, type aliases, separate compilation of algorithms and data structures, and implicit argument t...

Sigplan Notices, 2003

This paper describes how to add first-class generic typesincluding mixins-to strongly-typed OO languages with nominal subtyping such as Java and C#. A generic type system is "first-class" if generic types can appear in any context where conventional types can appear. In this context, a mixin is simply a generic class that extends one of its type parameters, e.g., a class C<T> that extends T. Although mixins of this form are widely used in C++ (via templates), they are clumsy and error-prone because C++ treats mixins as macros, forcing each mixin instantiation to be separately compiled and type-checked. The abstraction embodied in a mixin is never separately analyzed.

ACM SIGPLAN Notices, 2005

Concepts are an essential language feature for generic programming in the large. Concepts allow for succinct expression of constraints on type parameters of generic algorithms, enable systematic organization of problem domain abstractions, and make generic algorithms easier to use. In this paper we present the design of a type system and semantics for concepts that is suitable for non-type-inferencing languages. Our design shares much in common with the type classes of Haskell, though our primary influence is from best practices in the C++ community, where concepts are used to document type requirements for templates in generic libraries. Concepts include a novel combination of associated types and same-type constraints that do not appear in type classes, but that are similar to nested types and type sharing in ML.

Lecture Notes in Computer Science, 2000

programming depends on the decomposition of programs into components which may be developed separately and combined arbitrarily, subject only to well-defined interfaces. Among the interfaces of interest, indeed the most pervasively and unconsciously used, are the fundamental operators common to all C++ built-in types, as extended to user-defined types, e.g. copy constructors, assignment, and equality. We investigate the relations which must hold among these operators to preserve consistency with their semantics for the built-in types and with the expectations of programmers.

2003

We describe a design pattern for writing programs that traverse data structures built from rich mutually-recursive data types. Such programs often have a great deal of "boilerplate" code that simply walks the structure, hiding a small amount of "real" code that constitutes the reason for the traversal.

2012

In Haskell, there is a clear distinction between values, types, and kinds. Values are built with constructors, such as True, which we colour in blue; we do not colour numerals, characters, or strings: Just 3, (Right 'p' Left "abc"). Datatypes, type synonyms, type variables, indexed families, and type classes are coloured in orange: Bool, Show α ⇒ Show [ α ], type family PF α. Kinds and kind variables are coloured in green: , → , Constraint. For simplicity we do not colour the arrow operator, as it can appear at different levels. Agda code The distinction between values and types is less clear in Agda. Our convention is to use blue for constructors (e.g. refl), orange for identifiers of type Set (e.g. _≡_), and green for identifiers of type Set 1 or (for simplicity) higher (e.g. Set). 2.2.3 Isomorphisms We have mentioned that some types are equivalent to others without formally defining this equivalence. When we say two types are equivalent we mean that they are isomorphic. The concept of isomorphism can be succinctly summarised as an Agda record type: