In Java world, the naming conventions for interfaces are pretty much well established. For instance, when you say certain class implements the interface Comparable
,
Actually, things are mostly straightforward in Haskell: Type classes are typically named based on what the operations represent, not what the type parameter represents.
For example:
Read
, Show
: Classes of types for which standard string serialization/deserialization functions are defined.Eq
, Ord
: Classes of types on which equality and ordering relations, respectively, are defined.Enum
: The class of types defining a "successor" operation, i.e., whose values can be enumerated.Monoid
, Functor
, Monad
: Classes of types which define the operations associated with the similarly-named mathematical structures.Some examples aren't so good: For instance, Num
is a class of types on which an ad-hoc collection of vaguely-arithmetic-oriented operations are defined, but there's no reason that an instance of Num
must actually be a number in any conventional sense. This could perhaps be handwaved as "types supporting numeric operations", pretending that "numeric" actually means anything in that phrase.
In short, Numeric
is probably a bad example to imitate, and if a type class has only one function (possibly with multiple variants on it), it's almost always safe to name the class after that function, as with show
vs. Show
.
But really, the main thing is to think in terms of the functions on the type class, not the type parameter. Think verbs, not nouns. Nouns are dumb inert things anyway, so thinking in terms of actions and operations is likely to lead to better program design.