# Monoid

A monoid is an algebraic structure comprising a product of *three* things

- a set;
- a closed binary operation; and
- an element of the set that is neutral with respect to that binary operation.

The binary operation must be *associative*.

In other words, a monoid is a semigroup with one additional requirement: the identity value.

Many sets form monoids under more than one operation. Integers, for example, form monoids under both sum and product operations, with 0 being the neutral element for addition and 1 being the identity for multiplication.

## The `Monoid`

class

In Haskell, monoids are represented by the `Monoid`

class. `Monoid`

is superclassed by `Semigroup`

Since `base-4.11.0.0`

., which means there is a `Semigroup`

constraint on the `Monoid`

class in the class definition. This means that in order to have a `Monoid`

instance, a type must also have a `Semigroup`

instance. `Data.Monoid`

.

```
class Semigroup a => Monoid a where
mempty :: a
mappend :: a -> a -> a
mconcat :: [a] -> a
{-# MINIMAL mempty #-}
```

The `mappend`

function was formerly part of the minimal complete definition of `Monoid`

, and `<>`

was its infix version; however, since all `Monoid`

s must also be `Semigroup`

s, the presence of `mappend`

in `Monoid`

is superfluous. The default implementation of `mappend`

is `mappend = (<>)`

since `base-4.11.0.0`

. The binary operation for a monoid is its implementation of `<>`

from the `Semigroup`

class. You may still use `mappend`

if you prefer prefix functions in some cases, and for historical reasons, you’ll still see it in a lot of Haskell code.

Now the only thing that must be implemented for an `instance`

of `Monoid`

is `mempty`

. As you can see, it’s not a functionIn some senses, it is a function. Since a typeclass can also be conceived as a *record of functions* that is passed around implicitly, the `Monoid a =>`

constraint on `mempty`

can be read as a function: it needs to be applied to a *type* in order to return the value., but nevertheless it’s very important: it defines the identity or neutral element with regard to the set and the particular operation. Thus, for numbers that form a monoid under addition, denoted with the `Sum`

newtype, `mempty`

would be `Sum 0`

; for the `Product`

newtype, it would be `Product 1`

.

```
λ> Sum 2 <> Sum 0
Sum {getSum = 2}
λ> Sum 2 <> mempty
Sum {getSum = 2}
λ> Product 1 <> Product 5
Product {getProduct = 5}
λ> mempty <> Product 5
Product {getProduct = 5}
λ> Product 0 <> Product 5
Product {getProduct = 0}
```

`mempty`

is *return-type polymorphic* and is extremely useful in writing polymorphic functions where an identity value of some kind will be needed but the type cannot yet be known. For example, we see this commonly used in the `pure`

implementation for `Applicative`

instances on certain species of types, such as tuples:

```
instance Monoid a => Applicative ((,) a) where
pure x = (mempty, x)
(x, func) <*> (y, z) = (x <> y, func z)
liftA2 func (x, z) (y, z') = (x <> y, func z z')
```

It’s worth noting that `Monoid`

should obey *right and left* identity laws. It shouldn’t too be surprising given what we expect of an identity value; if it’s neutral with respect to the operation, it should be neutral regardless of whether it’s the first argument or the second.

For example, it would be a truly unwanted surprise if multiplying by 1 gave you a different result depending on which position the 1 was in.

This is particularly trivial, though, since multiplication is known to be commutative, and not all monoids are commutative. For example, list concatenation is associative but not commutative: changing the order of arguments in list concatenation gives different results.

However, it is still the case that its `mempty`

behaves itself as both the right and left identity.

If you have two monoids over the same set, you *might* have a semiring.