[Haskell-cafe] Monads vs. monoids

Olaf Klinke olf at aatal-apotheke.de
Tue Jul 17 20:23:43 UTC 2018

>Am 16.07.2018 um 21:48 schrieb Olaf Klinke:
>> Joachim Durchholz wrote:
>>> Nope, monoid is a special case of monad (the case where all input and
>>> output types are the same).
>>> (BTW monoid is associativity + neutral element. Not 100% sure whether
>>> monad's "return" qualifies as a neutral element, and my
>>> monoid-equals-monotyped-monad claim above may fall down if it is not.
>> For every monad M, the type M () is a monoid,
>That doesn't make M a monoid, just its type.
>Besides, type-level monoids aren't relevant to data-level properties.

I'm sorry, I misunderstood your question, then. Of course monads are not 
You could say that every monad harbors a monoid, and that every monoid 
arises this way. But of course the whole and the part are not the same.

>> Does every monoid arise this way? Yes: Since base-4.9 there is the 
>> monad instance
>> Monoid a => Monad ((,) a)
>> and of course a and (a,()) are isomorphic (disregarding bottoms).
>An isomorphism does not make it the same, just easily mappable.
>This is pretty near to hair-splitting, I know.
>However, from a software design perspective, it's important to keep
>things separate even if they are easily mappable: temperatures are just
>floats, it's an incredibly easy mapping - but the code becomes clearer
>and more maintainable if you keep the Temperature type separate from the
>Float type. You may even want to forbid multiplying Temperatures (but
>you want the ability to multiply with a number, and temperature
>quotients can be useful, too).

I totally agree. As a domain theorist I am aware that a and (a,()) are not 
isomorphic because neither is () the terminal object of Hask nor is (,) 
the categorical product. But in terms of total elements, there is a monoid 
isomorphism between the two.

>Not 100% sure how much of this is really applicable.
>> Also, there is the famous tongue-in-cheek saying "monads are just
>> monoids in the category of endofunctors"
>Tongue-in-check does not make it real.
>And being a monoid in a category does not make it a monoid directly.

That depends on the definition of "monoid". If a monoid is a set with 
certain structure, then a monad is not a monoid. If a monoid is a monoid 
object in some monoidal category, then a monad is a monoid. Maybe we can 
agree on this distinction?
monoid = monoid object in Set
monoid object = any monoid object in monoidal closed category.
>There's also a final argument: If monad and monoid are really the same,
>why do mathematicians still keep the separate terminology?

Because they are different, as we hopefully agree.


More information about the Haskell-Cafe mailing list