[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
monoids.
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.
Olaf
More information about the Haskell-Cafe
mailing list