For people who haven’t done abstract algebra, don’t be put off by the word “monoid”. A monoid in algebra is just a set with some associative binary operation and an identity element. Mathematicians in the 19th and 20th centuries realised you can study these types of structures and prove things which are true for all of them rather than having to do each one separately, and that led to “abstract algebra”.
So for example, if I have the integers and multiplication, this is a monoid[1]. The identity element is zero, which is an integer, and multiplication is an associative binary operation. It takes two integers and returns an integer.
Once you realise you have a monoid, if you do maths that only relies on the monoid properties then it applies to all monoids, so you could drop a different monoid in there and everything would still work. This ends up being very much like how typeclasses work in Haskell or traits in Rust.
[1] For the curious, it’s not a “group” because the integers don’t have multiplicative inverses. If I have x=2, there is no integer that I can multiply that by to get 1. Integers with addition on the other hand is a group, which is a monoid with the additional property that inverses are present.
Somebody asked in a now-deleted comment: 'Right, and what does it mean in the context of "A monad is just a monoid in the category of endofunctors"?'
Here is an answer to this question:
What the parent poster referred to are "monoids in the category of sets". You can recognize this as they have introduced the carrier as (just a) set.
But the notion can be generalized. For instance, a "monoid in the category of datatypes" would not be given by a mathematical set and a mathematical binary operation, but by a datatype and a computable binary operation. (To make this precise, I would need to fix which "category of datatypes" I have in mind. It could be the category of Haskell types and Haskell functions, for instance; but C types and functions would work just as well. I could also go all the way to the effective topos, which contains lots of types which most mainstream programming languages are missing such as true quotient types.)
Finally, a "monoid in the category of endofunctors" is given by an endofunctor and a natural transformation. Endofunctors can be pictured as container kinds (e.g. ordered lists, unordered lists, Maybe/Optional, trees, vectors of length n, pairs, ...) and the additional datum of the natural transformation is what singles out those container kinds which support a "flattening operation" from those which don't. For instance, we can flatten a list of lists into one (long) list, but we cannot flatten a pair of pairs into one pair (we would need to drop two of the four elements).
Just as it is quite convenient that many results about integers or lists also hold for all monoids in the category of sets, it is quite nice that many results about monoids in the category of sets also hold for all monoids in all categories and hence in particular to monads.
For the curious, it’s not a “group” because the integers don’t have multiplicative inverses. If I have x=2, there is no integer that I can multiply that by to get 1. Integers with addition on the other hand is a group, which is a monoid with the additional property that inverses are present.
Would one be correct to say that square matrices are an example of monoids, since they have an identity element and are associative, but might not necessarily have inverses if their determinant is zero?
Additionally, if you restrict to invertible matrices with matrix multiplication, they are also a monoid (so they are a submonoid), and in fact a group, the general linear group. If you restrict again to matrices with determinant 1, it's again itself a group (a subgroup, and also a submonoid), the special linear group.
The operation is important too. Square matrices over integers with matrix multiplication is (just) a monoid. Square matrices with addition are a monoid too (but also a group, because there is an additive inverse).
For people who haven’t done abstract algebra, don’t be put off by the word “monoid”. A monoid in algebra is just a set with some associative binary operation and an identity element. Mathematicians in the 19th and 20th centuries realised you can study these types of structures and prove things which are true for all of them rather than having to do each one separately, and that led to “abstract algebra”.
So for example, if I have the integers and multiplication, this is a monoid[1]. The identity element is zero, which is an integer, and multiplication is an associative binary operation. It takes two integers and returns an integer.
Once you realise you have a monoid, if you do maths that only relies on the monoid properties then it applies to all monoids, so you could drop a different monoid in there and everything would still work. This ends up being very much like how typeclasses work in Haskell or traits in Rust.
[1] For the curious, it’s not a “group” because the integers don’t have multiplicative inverses. If I have x=2, there is no integer that I can multiply that by to get 1. Integers with addition on the other hand is a group, which is a monoid with the additional property that inverses are present.
Somebody asked in a now-deleted comment: 'Right, and what does it mean in the context of "A monad is just a monoid in the category of endofunctors"?'
Here is an answer to this question:
What the parent poster referred to are "monoids in the category of sets". You can recognize this as they have introduced the carrier as (just a) set.
But the notion can be generalized. For instance, a "monoid in the category of datatypes" would not be given by a mathematical set and a mathematical binary operation, but by a datatype and a computable binary operation. (To make this precise, I would need to fix which "category of datatypes" I have in mind. It could be the category of Haskell types and Haskell functions, for instance; but C types and functions would work just as well. I could also go all the way to the effective topos, which contains lots of types which most mainstream programming languages are missing such as true quotient types.)
Finally, a "monoid in the category of endofunctors" is given by an endofunctor and a natural transformation. Endofunctors can be pictured as container kinds (e.g. ordered lists, unordered lists, Maybe/Optional, trees, vectors of length n, pairs, ...) and the additional datum of the natural transformation is what singles out those container kinds which support a "flattening operation" from those which don't. For instance, we can flatten a list of lists into one (long) list, but we cannot flatten a pair of pairs into one pair (we would need to drop two of the four elements).
Just as it is quite convenient that many results about integers or lists also hold for all monoids in the category of sets, it is quite nice that many results about monoids in the category of sets also hold for all monoids in all categories and hence in particular to monads.
> The identity element is zero
I think the identity element would be 1 for integers and multiplication, right?
0 would be the identity element for integers and addition.
That and also why start with multiplication? String concatenation, addition, list concatenation all make more intuitive sense to a working programmer.
What's a straightforward way to combine a bunch of numbers? Just keep multiplying them to get a resulting volume in an ever-higher dimensional space.
Yes. Sorry I edited my original to change the operation.
Additionally, if you restrict to invertible matrices with matrix multiplication, they are also a monoid (so they are a submonoid), and in fact a group, the general linear group. If you restrict again to matrices with determinant 1, it's again itself a group (a subgroup, and also a submonoid), the special linear group.
The operation is important too. Square matrices over integers with matrix multiplication is (just) a monoid. Square matrices with addition are a monoid too (but also a group, because there is an additive inverse).
Put it all together and it’s called a ring
Yes
Interesting topic, too bad I didn't know about this a few years ago..