[Haskell-cafe] Monads vs. monoids

[Joachim Durchholz]

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.

> 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).
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.

There's also a final argument: If monad and monoid are really the same, 
why do mathematicians still keep the separate terminology?

Regards,
Jo