Re: [Haskell-cafe] Monads vs. monoids
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
Am 17.07.2018 um 22:23 schrieb Olaf Klinke:
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.
Agreed.
That depends on the definition of "monoid". If a monoid is a set with certain structure, then a monad is not a monoid.
That's the perspective from which I'm looking at abstract data types: A set of values, a set of operations, a set of axioms over the operations and values. Well, that's the textbook definition, there's a lot of data structures that have multiple value sets but still are related through axioms. I just don't know an example of such a structure that it could make it into the textbooks :-) From that perspective, monads and monoids are distinct. Even fundamentally so: Monad axioms have more type parameters than monoid axioms, so they cannot be made isomorphic by clever transformations.
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.
We do :-) Regards, Jo
There is more to this picture. If you have a set G then lists of elements of G is the free monoid. You get a list only because the category of sets is monoidal with the monoidal product the cartesian product. The same construction can be carried to free monads, but in a different category: the monoidal category of endofunctors, where the monoidal product is functor composition, so you'll end up with a recursive thing build in much of the same way. I recently wrote a blog posts about it: https://marcinszamotulski.me/posts/free-monads.html - if you're not afraid of some mathematics (universal algebra and just a bit of category theory).
Free construction carries all the structure of monoids or monads: having free monoid / monad you can get back `mempty` and `mappend` (or `return` and `join` / `>>=`) for any other monoid / monad.
Best regards,
Marcin
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 17, 2018 10:36 PM, Joachim Durchholz
Am 17.07.2018 um 22:23 schrieb Olaf Klinke:
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.
Agreed.
That depends on the definition of "monoid". If a monoid is a set with
certain structure, then a monad is not a monoid.
That's the perspective from which I'm looking at abstract data types: A
set of values, a set of operations, a set of axioms over the operations
and values.
Well, that's the textbook definition, there's a lot of data structures
that have multiple value sets but still are related through axioms. I
just don't know an example of such a structure that it could make it
into the textbooks :-)
From that perspective, monads and monoids are distinct.
Even fundamentally so: Monad axioms have more type parameters than
monoid axioms, so they cannot be made isomorphic by clever transformations.
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.
We do :-)
Regards,
Jo
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
participants (3)
-
Joachim Durchholz -
Marcin Szamotulski -
Olaf Klinke