Modular Type Classes Derek Dreyer Robert Harper Manuel M.T. Chakravarty Toyota Technological Institute at Chicago Carnegie Mellon University University of New South Wales [email protected] [email protected] [email protected] Abstract polymorphic instantiation with instances of type classes. There is a ML modules and Haskell type classes have proven to be highly ef- clear correspondence between the highlighted concepts (see [24]), fective tools for program structuring. Modules emphasize explicit and consequently modules and type classes are sometimes regarded configuration of program components and the use of data abstrac- as opposing approaches to language design. We show that there is tion. Type classes emphasize implicit program construction and no opposition. Rather, type classes and modules are complemen- ad hoc polymorphism. In this paper, we show how the implicitly- tary aspects of a comprehensive framework of modularity. typed style of type class programming may be supported within Perhaps the most significant difference is the mode of use of the the framework of an explicitly-typed module language by viewing two concepts. The Haskell type class system is primarily intended type classes as a particular mode of use of modules. This view of- to support ad hoc polymorphism in the context of a parametrically fers a harmonious integration of modules and type classes, where polymorphic language. It emphasizes the implicit inference of class type class features, such as class hierarchies and associated types, constraints and automatic construction of instances during overload arise naturally as uses of existing module-language constructs, such resolution, which makes it convenient to use in many common as module hierarchies and type components. In addition, program- cases, but does not facilitate more general purposes of modular mers have explicit control over which type class instances are avail- programming. Moreover, the emphasis on automatic generation able for use by type inference in a given scope. We formalize our of instances imposes inherent limitations on expressiveness—most approach as a Harper-Stone-style elaboration relation, and provide importantly, there can be at most one instance of a type class at any a sound type inference algorithm as a guide to implementation. particular type. In contrast, the ML module system is designed to support the Categories and Subject Descriptors D.3.1 [Programming Lan- structuring of programs by forming hierarchies of components and guages]: Formal Definitions and Theory; D.3.3 [Programming imposing abstraction boundaries—both client-side abstraction, via Languages]: Language Constructs and Features—Polymorphism, functors, and implementor-side abstraction, via signature ascription Modules; F.3.3 [Logics and Meanings of Programs]: Studies of (aka sealing). The module system emphasizes explicit manipula- Program Constructs—Type structure tion of modules in the program, which makes it more flexible and general than the type class mechanism. Modules may be ascribed General Terms Design, Languages, Theory multiple signatures that reveal varying amounts of type informa- Keywords Type classes, modules, type inference, type systems tion, signatures may be implemented by many modules, and neither modules nor signatures are restricted to have the rigid form that Haskell’s instances and classes have. On the other hand, ML lacks 1. Introduction support for implicit module generation and ad hoc polymorphism, The ML module system [17] and the Haskell type class system [23, features which experience with Haskell has shown to be convenient 19] have proved, through more than 15 years of practical experi- and desirable. ence and theoretical analysis, to be effective linguistic tools for There have been many proposals to increase the expressive- structuring programs. Each provides the means of specifying the ness of the original type class system as proposed by Wadler and functionality of program components, abstracting programs over Blott [23], including constructor classes [15], functional dependen- such specifications, and instantiating programs with specific real- cies [12], named instances [16], and associated types [2, 1]. These izations of the specifications on which they depend. In ML such may all be seen as adding functionality to the Haskell class system specifications are called signatures, abstraction is achieved through that mirrors aspects of the ML module system, while retaining the functors, and instantiation is achieved by functor application to implicit style of usage of type classes. However, these (and other) structures that implement these signatures. In Haskell such spec- extensions tend to complicate the type class system without allevi- ifications are called type classes, abstraction is achieved through ating the underlying need for a more expressive module system. constrained polymorphism, and instantiation is achieved through In fact, there are ways in which the Haskell type class mech- anism impedes modularity. To support implicit instance genera- tion while ensuring coherence of inference, Haskell insists that instances of type classes be drawn from a global set of instance declarations; in particular, instances are implicitly exported and imported, which puts their availability beyond programmer con- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed trol. This can be quite inconvenient—for many type classes there is for profit or commercial advantage and that copies bear this notice and the full citation more than one useful instance of the class at a particular type, and on the first page. To copy otherwise, to republish, to post on servers or to redistribute the appropriate choice of instance depends on the context in which to lists, requires prior specific permission and/or a fee. an overloaded operator is used. Hence, the Haskell Prelude must POPL’07 January 17–19, 2007, Nice, France. provide many functions in two versions: one using type classes and Copyright c 2007 ACM 1-59593-575-4/07/0001. $5.00. the other an explicit function argument—e.g., sort and sortBy. 63 In this paper we take a different tack. Rather than bolster the eter). In particular, we insist that the distinguished type component expressiveness of type classes, we instead propose that a more sen- be named “t”. It may be followed by any number of other type, sible approach to combining the benefits of type classes and mod- value, or substructure components. We call such a signature a class ules is to start with modules as the fundamental concept, and then signature, specifically an atomic class signature (in contrast to the recover type classes as a particular mode of use of modularity. We composite ones that we describe below in Section 2.3.) For exam- retain the advantages of a fully expressive explicit module system, ple, the class of equality types is represented by the atomic class while also offering the conveniences of implicit type class program- signature EQ, defined as follows: ming, particularly the integration of ad hoc and parametric poly- signature EQ = sig morphism. Moreover, the proposed design provides a clean separa- type t tion between the definition of instances and their availability for use val eq : t * t -> bool during type inference. This offers localization of instance scoping, end enhanced readability, and the potential for instances to be compiled separately from their uses. The result is a harmonious integration Note that class signatures like EQ are just ordinary ML signatures of modules and type classes that provides the best features of both of a certain specified form. approaches in a single, consistent framework. The elegance of our Correspondingly, an instance of a type class is represented by a approach stems from the observation that type class features, such module. A monomorphic instance of a type class is represented by as class hierarchies and associated types, arise naturally as uses of a structure, and a polymorphic instance is represented by a functor. existing module-language constructs, such as module hierarchies For example, we can encode an int instance of the equality class and type components. as a structure whose signature is EQ where type t = int: In summary, this paper makes the following contributions: structure EqInt = struct • We present a smooth integration of type classes and mod- type t = int ules that provides a foundation for future work on incorpo- val eq = Int.eq rating type classes into ML and a proper module system into end Haskell. We give an intuition of the integration of type classes As in Haskell, the instance for a compound type t(t1,...,tn) is into ML in Section 2. t ,...,t • composed from instances of its component types, 1 n,bya We highlight some interesting design issues that arose while functor, Eq , associated with its outermost type constructor, t.For developing the interpretation of type classes in terms of mod- t example, here is an instance of equality for product types t1 * t2: ules (Section 3). • We specify the semantics of an extended module language functor EqProd (X : EQ, Y : EQ) = struct that supports type classes. We formalize its elaboration (in type t = X.t * Y.t the style of Harper and Stone [9]) into an explicitly-typed fun eq ((x1,y1), (x2, y2)) = module type system. We also generalize Damas and Milner’s X.eq(x1,x2) andalso Y.eq(y1,y2) Algorithm W [3] to an inference algorithm for modular type end classes that we have proved sound with respect to the elab- There is an evident correspondence with Haskell instance decla- oration semantics. Due to space limitations, Section 4 only rations, but rather than use Horn clause logic programs to specify sketches the most salient and unusual features of our formal- closure conditions, we instead use functional programs (in the form ization. For the full formalization of our language, together of functors). with expanded technical discussion and theorem statements, From the EqInt and EqProd modules we can construct an we refer the reader to our companion technical report [7].