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.
In Haskell, monoids are represented by the
Monoid is superclassed by
base-126.96.36.199., 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
mappend function was formerly part of the minimal complete definition of
<> was its infix version; however, since all
Monoids must also be
Semigroups, the presence of
Monoid is superfluous. The default implementation of
mappend = (<>) since
base-188.8.131.52. 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
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
mempty would be
Sum 0; for the
Product newtype, it would be
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:
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.