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