[Haskell-cafe] Monads vs. monoids
jo at durchholz.org
Tue Jul 17 07:30:04 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.
> Does every monoid arise this way? Yes: Since base-4.9 there is the monad
> 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?
More information about the Haskell-Cafe