All basic datatypes (like Int, String, Eq a => [a]) from Prelude except for functions and IO have instances of Eq. If a type instantiates Eq it means that we know how to compare two values for value or structural equality.

> 3 == 2 
False
> 3 == 3
True

Required methods

• (==) :: Eq a => a -> a -> Boolean or (/=) :: Eq a => a -> a -> Boolean (if only one is implemented, the other defaults to the negation of the defined one)

Defines

• (==) :: Eq a => a -> a -> Boolean
• (/=) :: Eq a => a -> a -> Boolean

Direct superclasses

None

Notable subclasses

• Ord (opens new window)

Types instantiating Ord include, e.g., Int, String, and [a] (for types a where there's an Ord a instance). If a type instantiates Ord it means that we know a “natural” ordering of values of that type. Note, there are often many possible choices of the “natural” ordering of a type and Ord forces us to favor one.

Ord provides the standard (<=), (<), (>), (>=) operators but interestingly defines them all using a custom algebraic data type

data Ordering = LT | EQ | GT

compare :: Ord a => a -> a -> Ordering

Required methods

• compare :: Ord a => a -> a -> Ordering or (<=) :: Ord a => a -> a -> Boolean (the standard’s default compare method uses (<=) in its implementation)

Defines

• compare :: Ord a => a -> a -> Ordering
• (<=) :: Ord a => a -> a -> Boolean
• (<) :: Ord a => a -> a -> Boolean
• (>=) :: Ord a => a -> a -> Boolean
• (>) :: Ord a => a -> a -> Boolean
• min :: Ord a => a -> a -> a
• max :: Ord a => a -> a -> a

Direct superclasses

• Eq (opens new window)

Types instantiating Monoid (opens new window) include lists, numbers, and functions with Monoid return values, among others. To instantiate Monoid a type must support an associative binary operation (mappend or (<>)) which combines its values, and have a special "zero" value (mempty) such that combining a value with it does not change that value:

mempty  <>  x == x
x <>  mempty  == x

x <> (y <> z) == (x <> y) <> z

Intuitively, Monoid types are "list-like" in that they support appending values together. Alternatively, Monoid types can be thought of as sequences of values for which we care about the order but not the grouping. For instance, a binary tree is a Monoid, but using the Monoid operations we cannot witness its branching structure, only a traversal of its values (see Foldable and Traversable).

Required methods

• mempty :: Monoid m => m
• mappend :: Monoid m => m -> m -> m

Direct superclasses

None

The most general class for number types, more precisely for rings (opens new window), i.e. numbers that can be added and subtracted and multiplied in the usual sense, but not necessarily divided.

This class contains both integral types (Int, Integer, Word32 etc.) and fractional types (Double, Rational, also complex numbers etc.). In case of finite types, the semantics are generally understood as modular arithmetic, i.e. with over- and underflow^†.

Note that the rules for the numerical classes are much less strictly obeyed than the monad (opens new window) or monoid laws, or those for equality comparison (opens new window). In particular, floating-point numbers generally obey laws only in a approximate sense.

The methods

  a + (b + c) ≡ (a + b) + c
  a + b ≡ b + a

  (a - b) + b ≡ (a + b) - b ≡ a

  a * (b * c) ≡ (a * b) * c
  a * (b + c) ≡ a * b + a * c

  -a ≡ negate a ≡ 0 - a

  abs (-a) ≡ abs a
  abs (abs a) ≡ abs a

  abs (signum a) ≡ 1   -- unless a≡0
  signum a * abs a ≡ a -- This is required to be true for all Num instances

Some libraries, notably linear (opens new window) and hmatrix (opens new window), have a much laxer understanding of what the Num class is for: they treat it just as a way to overload the arithmetic operators. While this is pretty straightforward for + and -, it already becomes troublesome with * and more so with the other methods. For instance, should * mean matrix multiplication or element-wise multiplication?
It is arguably a bad idea to define such non-number instances; please consider dedicated classes such as VectorSpace (opens new window).

^† _{In particular, the “negatives” of unsigned types are wrapped around to large positive, e.g. (-4 :: Word32) == 4294967292.}

^‡ _{This is widely not fulfilled: vector types do not have a real subset. The controversial Num-instances for such types generally define abs and signum element-wise, which mathematically speaking doesn't really make sense.}

In Haskell, data types can have arguments just like functions. Take the Maybe type for example.

Maybe is a very useful type which allows us to represent the idea of failure, or the possiblity thereof. In other words, if there is a possibility that a computation will fail, we use the Maybe type there. Maybe acts kind of like a wrapper for other types, giving them additional functionality.

Its actual declaration is fairly simple.

Maybe a = Just a | Nothing

What this tells is that a Maybe comes in two forms, a Just, which represents success, and a Nothing, which represents failure. Just takes one argument which determines the type of the Maybe, and Nothing takes none. For example, the value Just "foo" will have type Maybe String, which is a string type wrapped with the additional Maybe functionality. The value Nothing has type Maybe a where a can be any type.

This idea of wrapping types to give them additional functionality is a very useful one, and is applicable to more than just Maybe. Other examples include the Either, IO and list types, each providing different functionality. However, there are some actions and abilities which are common to all of these wrapper types. The most notable of these is the ability to modify the encapsulated value.

It is common to think of these kinds of types as boxes which can have values placed in them. Different boxes hold different values and do different things, but none are useful without being able to access the contents within.

To encapsulate this idea, Haskell comes with a standard typeclass, named Functor. It is defined as follows.

class Functor f where
  fmap :: (a -> b) -> f a -> f b

As can be seen, the class has a single function, fmap, of two arguments. The first argument is a function from one type, a, to another, b. The second argument is a functor (wrapper type) containing a value of type a. It returns a functor (wrapper type) containing a value of type b.

In simple terms, fmap takes a function and applies to the value inside of a functor. It is the only function necessary for a type to be a member of the Functor class, but it is extremely useful. Functions operating on functors that have more specific applications can be found in the Applicative and Monad typeclasses.

Haskell supports a notion of class extension. For example, the class Ord inherits all of the operations in Eq, but in addition has a compare function that returns an Ordering between values. Ord may also contain the common order comparison operators, as well as a min method and a max method.

The => notation has the same meaning as it does in a function signature and requires type a to implement Eq, in order to implement Ord.

data Ordering = EQ | LT | GT

class Eq a => Ord a where
    compare :: Ord a => a -> a -> Ordering
    (<)     :: Ord a => a -> a -> Bool
    (<=)    :: Ord a => a -> a -> Bool
    (>)     :: Ord a => a -> a -> Bool
    (>=)    :: Ord a => a -> a -> Bool
    min     :: Ord a => a -> a -> a
    max     :: Ord a => a -> a -> a

All of the methods following compare can be derived from it in a number of ways:

x < y   = compare x y == LT
x <= y  = x < y || x == y -- Note the use of (==) inherited from Eq
x > y   = not (x <= y)
x >= y  = not (x < y)

min x y = case compare x y of
               EQ -> x
               LT -> x
               GT -> y

max x y = case compare x y of
               EQ -> x
               LT -> y
               GT -> x

Type classes that themselves extend Ord must implement at least either the compare method or the (<=) method themselves, which builds up the directed inheritance lattice.

Remarks

The following diagram taken from the Typeclassopedia (opens new window) article shows the relationship between the various typeclasses in Haskell.

(opens new window)