In other words though, for those just starting their monad journey:
An endofunctor is a box. If you have a box of soup, and a function to turn soup into nuts, you can probably turn the box of soup into a box of nuts. You don’t have to write a new function for this, if the box can take your existing function and “apply” it to its contents.
Arrays are endofunctors, because they hold things, and you can use Array.map to turn an array of X into an array of Y.
Monoids are things you can add together. Integer plus integer equals integer, so ints are monoids. String plus string (concatenation) equals a longer string, so strings are monoids. Grocery lists are monoids.
Arrays are monoids!
Arrays are both endofunctors and monoids, so for everyone except category theory purists, they are monads.
Javascript promises hold things, and you can transform their contents with .then - so they are endofunctors. You can “add them together” with Promise.all (returning a new promise), so they are monoids. They are both monoids and endofunctors, so they are monads.
I’ve just upset all the category theorists, but in the context of programming, that’s all it is. It’s surprisingly simple once you get it, it’s just complicated names for simple features.
They’re close, but not quite. then can shift semantics from under you depending on what’s supplied.
It should also be added that monoids require the type to have an identity or “empty” value (which is the empty array for arrays).
The explanation is pretty off in general, since it implies that any type that’s both a functor and a monoid is a monad, which is simply not true. A good example is a ZipList (like lists, but with an applicative instance based on zipping). It’s a functor and a monoid, but definitely not a monad.
IIRC monoid also requires you to have zero, so that an initial value is known for any repetitive operation. In case of an array that’d be an empty one, in case of promise that’d be doing nothing, I guess.
Indeed, the identity element. I can’t remember if it’s required or just a nice to have - I’m leaning in agreement towards required.
Zero for integers, the empty string, an empty array, Promise.resolve(), an empty grocery list.
There’s a fantastic blog post out there, I can’t recall the name, that talks about modeling things with monoids - a list of package dependencies, for ex, is a monoid.
I believe there’s a similar identity concept for endofunctors, ie some identity function that does not modify their contents, ex ((a)=>a)
A monad is just a monoid in the category of endofunctors. Everyone knows that!
Of course!
In other words though, for those just starting their monad journey:
An endofunctor is a box. If you have a box of soup, and a function to turn soup into nuts, you can probably turn the box of soup into a box of nuts. You don’t have to write a new function for this, if the box can take your existing function and “apply” it to its contents.
Arrays are endofunctors, because they hold things, and you can use Array.map to turn an array of X into an array of Y.
Monoids are things you can add together. Integer plus integer equals integer, so ints are monoids. String plus string (concatenation) equals a longer string, so strings are monoids. Grocery lists are monoids.
Arrays are monoids!
Arrays are both endofunctors and monoids, so for everyone except category theory purists, they are monads.
Javascript promises hold things, and you can transform their contents with .then - so they are endofunctors. You can “add them together” with Promise.all (returning a new promise), so they are monoids. They are both monoids and endofunctors, so they are monads.
I’ve just upset all the category theorists, but in the context of programming, that’s all it is. It’s surprisingly simple once you get it, it’s just complicated names for simple features.
“Complicated names for simple features” seems to describe Haskell crowd pretty well.
Thank you for a straightforward explanation!
JavaScript promises are not monads: https://stackoverflow.com/questions/45712106/why-are-promises-monads
They’re close, but not quite.
thencan shift semantics from under you depending on what’s supplied.It should also be added that monoids require the type to have an identity or “empty” value (which is the empty array for arrays).
The explanation is pretty off in general, since it implies that any type that’s both a functor and a monoid is a monad, which is simply not true. A good example is a
ZipList(like lists, but with an applicative instance based on zipping). It’s a functor and a monoid, but definitely not a monad.IIRC monoid also requires you to have
zero, so that an initial value is known for any repetitive operation. In case of an array that’d be an empty one, in case of promise that’d be doing nothing, I guess.Indeed, the identity element. I can’t remember if it’s required or just a nice to have - I’m leaning in agreement towards required.
Zero for integers, the empty string, an empty array, Promise.resolve(), an empty grocery list.
There’s a fantastic blog post out there, I can’t recall the name, that talks about modeling things with monoids - a list of package dependencies, for ex, is a monoid.
I believe there’s a similar identity concept for endofunctors, ie some identity function that does not modify their contents, ex ((a)=>a)
Duh!
Endodunctors? Now I have to know Minecraft too?