Type class

In computer science, a type class is a type system construct that supports ad hoc polymorphism. This is achieved by adding constraints to type variables in parametrically polymorphic types. Such a constraint typically involves a type class codice_1 and a type variable codice_2, and means that codice_2 can only be instantiated to a type whose members support the overloaded operations associated with codice_1.
Type classes were first implemented in the Haskell programming language after first being proposed by Philip Wadler and Stephen Blott as an extension to "eqtypes" in Standard ML, and were originally conceived as a way of implementing overloaded arithmetic and equality operators in a principled fashion.
In contrast with the "eqtypes" of Standard ML, overloading the equality operator through the use of type classes in Haskell does not require extensive modification of the compiler frontend or the underlying type system.
Since their creation, many other applications of type classes have been discovered.
Overview.
Type classes are defined by specifying a set of function or constant names, together with their respective types, that must exist for every type that belongs to the class. In Haskell, types can be parameterized; a type class codice_5 intended to contain types that admit equality would be declared in the following way:
class Eq a where
 (==) :: a -> a -> Bool
 (/=) :: a -> a -> Bool
where codice_2 is one instance of the type class codice_5, and codice_2 defines the function signatures for 2 functions (the equality and inequality functions), which each take 2 arguments of type codice_2 and return a boolean.
The type variable codice_2 has kind formula_1 (also known as codice_11 in the latest GHC release), meaning that the kind of codice_5 is
Eq :: Type -> Constraint
The declaration may be read as stating a "type codice_2 belongs to type class codice_5 if there are functions named codice_15, and codice_16, of the appropriate types, defined on it". A programmer could then define a function codice_17 (which determines if an element is in a list) in the following way:
elem :: Eq a => a -> [a] -> Bool
elem y [] = False
elem y (x:xs) = (x == y) || elem y xs
The function codice_17 has the type codice_19 with the context codice_20, which constrains the types which codice_2 can range over to those codice_2 which belong to the codice_5 type class. ("Note": Haskell codice_24 can be called a 'class constraint'.)
A programmer can make any type codice_25 a member of a given type class codice_26 by using an "instance declaration" that defines implementations of all of codice_26's methods for the particular type codice_25. For instance, if a programmer defines a new data type codice_25, they may then make this new type an instance of codice_5 by providing an equality function over values of type codice_25 in whatever way they see fit. Once they have done this, they may use the function codice_17 on codice_33, that is, lists of elements of type codice_25.
Note that type classes are different from classes in object-oriented programming languages. In particular, codice_5 is not a type: there is no such thing as a "value" of type codice_5.
Type classes are closely related to parametric polymorphism. For example, note that the type of codice_17 as specified above would be the parametrically polymorphic type codice_19 were it not for the type class constraint "codice_39".
Higher-kinded polymorphism.
A type class need not take a type variable of kind codice_11 but can take one of any kind. These type classes with higher kinds are sometimes called constructor classes (the constructors referred to are type constructors such as codice_41, rather than data constructors such as codice_42). An example is the codice_43 class:
class Monad m where
 return :: a -> m a
 (»=) :: m a -> (a -> m b) -> m b
The fact that m is applied to a type variable indicates that it has kind codice_44, i.e. it takes a type and returns a type, the kind of codice_43 is thus:
Monad :: (Type -> Type) -> Constraint
Multi-parameter type classes.
Type classes permit multiple type parameters, and so type classes can be seen as relations on types. For example, in the GHC standard library, the class codice_46 expresses a general immutable array interface. In this class, the type class constraint codice_47 means that codice_2 is an array type that contains elements of type codice_49. (This restriction on polymorphism is used to implement unboxed array types, for example.)
Like multimethods, multi-parameter type classes support calling different implementations of a method depending on the types of multiple arguments, and indeed return types. Multi-parameter type classes do not require searching for the method to call on every call at runtime; rather the method to call is first compiled and stored in the dictionary of the type class instance, just as with single-parameter type classes.
Haskell code that uses multi-parameter type classes is not portable, as this feature is not part of the Haskell 98 standard. The popular Haskell implementations, GHC and Hugs, support multi-parameter type classes.
Functional dependencies.
In Haskell, type classes have been refined to allow the programmer to declare functional dependencies between type parameters—a concept inspired from relational database theory. That is, the programmer can assert that a given assignment of some subset of the type parameters uniquely determines the remaining type parameters. For example, a general monad codice_50 which carries a state parameter of type codice_51 satisfies the type class constraint codice_52. In this constraint, there is a functional dependency codice_53. This means that for a given monad codice_50 of type class codice_55, the state type accessible from codice_50 is uniquely determined. This aids the compiler in type inference, as well as aiding the programmer in type-directed programming.
Simon Peyton-Jones has objected to the introduction of functional dependencies in Haskell on grounds of complexity.
Type classes and implicit parameters.
Type classes and implicit parameters are very similar in nature, although not quite the same. A polymorphic function with a type class constraint such as:
sum :: Num a => [a] -> a
can be intuitively treated as a function that implicitly accepts an instance of codice_57:
sum_ :: Num_ a -> [a] -> a
The instance codice_58 is essentially a record that contains the instance definition of codice_59. (This is in fact how type classes are implemented under the hood by the Glasgow Haskell Compiler.)
However, there is a crucial difference: implicit parameters are more "flexible" – you can pass different instances of codice_60. In contrast, type classes enforce the so-called "coherence" property, which requires that there should only be one unique choice of instance for any given type. The coherence property makes type classes somewhat antimodular, which is why orphan instances (instances that are defined in a module that neither contains the class nor the type of interest) are strongly discouraged. On the other hand, coherence adds an additional level of safety to the language, providing the programmer a guarantee that two disjoint parts of the same code will share the same instance.
As an example, an ordered set (of type codice_61) requires a total ordering on the elements (of type codice_2) in order to function. This can be evidenced by a constraint codice_63, which defines a comparison operator on the elements. However, there can be numerous ways to impose a total order. Since set algorithms are generally intolerant of changes in the ordering once a set has been constructed, passing an incompatible instance of codice_63 to functions that operate on the set may lead to incorrect results (or crashes). Thus, enforcing coherence of codice_63 in this particular scenario is crucial.
Instances (or "dictionaries") in Scala type classes are just ordinary values in the language, rather than a completely separate kind of entity. While these instances are by default supplied by finding appropriate instances in scope to be used as the implicit actual parameters for explicitly-declared implicit formal parameters, the fact that they are ordinary values means that they can be supplied explicitly, to resolve ambiguity. As a result, Scala type classes do not satisfy the coherence property and are effectively a syntactic sugar for implicit parameters.
This is an example taken from the Cats documentation:
// A type class to provide textual representation
trait Show[A] {
 def show(f: A): String
// A polymorphic function that works only when there is an implicit 
// instance of Show[A] available
def log[A](a: A)(implicit s: Show[A]) = println(s.show(a))
// An instance for String
implicit val stringShow = new Show[String] {
 def show(s: String) = s
// The parameter stringShow was inserted by the compiler.
scala> log("a string")
a string
Coq (version 8.2 onwards) also supports type classes by inferring the appropriate instances. Recent versions of Agda 2 also provide a similar feature, called "instance arguments".
Other approaches to operator overloading.
In Standard ML, the mechanism of "equality types" corresponds roughly to Haskell's built-in type class codice_5, but all equality operators are derived automatically by the compiler. The programmer's control of the process is limited to designating which type components in a structure are equality types and which type variables in a polymorphic type range over equality types.
SML's and OCaml's modules and functors can play a role similar to that of Haskell's type classes, the principal difference being the role of type inference, which makes type classes suitable for "ad hoc" polymorphism.
The object oriented subset of OCaml is yet another approach which is somewhat comparable to the one of type classes.
Related notions.
An analogous notion for overloaded data (implemented in GHC) is that of type family.
In Clean typeclasses are similar to Haskell, but have a slightly different syntax.
Rust supports traits, which are a limited form of type classes with coherence.
Mercury has typeclasses, although they are not exactly the same as in Haskell. 
In Scala, type classes are a programming idiom which can be implemented with existing language features such as implicit parameters, not a separate language feature per se. Because of the way they are implemented in Scala, it is possible to explicitly specify which type class instance to use for a type at a particular place in the code, in case of ambiguity. However, this is not necessarily a benefit as ambiguous type class instances can be error-prone.
The proof assistant Coq has also supported type classes in recent versions. Unlike in ordinary programming languages, in Coq, any laws of a type class (such as the monad laws) that are stated within the type class definition, must be mathematically proved of each type class instance before using them.