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.
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.