Monads are monoids in the category of endofunctors
21–30 of 241 posts
Re: Monads are monoids in the category of endofunctors
#22Re: Monads are monoids in the category of endofunctors
#23Re: Monads are monoids in the category of endofunctors
#24Contrary to this post, merely being a functor and a monoid does not make something a monad; for example any arbitrary monoid (say, the integers) could be considered an applicative via Const, but is not a monad. Or many other applicative-but-not-monads have monoidal structure, e.g. ZipList.
Re: Monads are monoids in the category of endofunctors
#25Wait, a functor is just a pure unary function? And an endofunctor is just one of those where the argument type and return type are the same? This could have been explained to me years ago, in five minutes? Sometimes it makes me mad that so much confusion (and as another commenter put it, gatekeeping) has been sown in FP circles through the invention of pointlessly-obfuscated terminology for everything (and through -…
> Wait, a functor is just a pure unary function? And guess what another name for a unary functions is... 'monadic'.
Re: Monads are monoids in the category of endofunctors
#26Wait, a functor is just a pure unary function? And an endofunctor is just one of those where the argument type and return type are the same? This could have been explained to me years ago, in five minutes? Sometimes it makes me mad that so much confusion (and as another commenter put it, gatekeeping) has been sown in FP circles through the invention of pointlessly-obfuscated terminology for everything (and through -…
No.
> And an endofunctor is just one of those where the argument type and return type are the same?
Yes - "endo" means that in general. E.g. endomorphism.
> Sometimes it makes me mad that so much confusion (and as another commenter put it, gatekeeping) has been sown in FP circles through the invention of pointlessly-obfuscated terminology for everything (and through - among many in those circles - a lack of interest in connecting the very simple dots that would allow masses of people to understand these concepts). It's like when the medieval Catholic Church refused to print a bible in anything but Latin so that they'd remain the sole authority on its content.
> Kudos to the OP for cutting through some of that, but shame on those who maintain this status quo.
> Edit: assuming it really is that simple. Some in the comments have suggested parts of the OP were wrong, so I'm curious to see discussion.
The precise terminology is vital; it's how we avoid these errors when talking about this very abstract stuff. Given that the OP is very wrong, precisely because of the kind of attitude you've taken here, I hope you'll take this opportunity to reconsider your views.
Re: Monads are monoids in the category of endofunctors
#27In particular there is an unwarranted leap here. If `numToStr` is a functor, then `addOne` (the function that just adds one to an integer) should be an endofunctor. So what's the monad?
Yet all of a sudden the article jumps to talking about `Array` as an endofunctor! Which is most definitely not a function like `numToStr` or `addOne`.
So which is it?
In particular,
> Of course, as we saw above, Arrays support a map method which allow us to transform the values of the array but do so in a way that returns an Array (the same type as the starting type), making them endofunctors.
Makes no sense combined with `numToStr`. What exactly is the `map` function for `numToStr`?
It turns out you can unify both of these notions, but you need the language of category theory to do it. But that's overkill for FP. So generally in FP a functor is just a type constructor (a type that takes another type as an argument e.g. `List` or `Option` or `Future`) with an associated `map` function that obeys the "law" that `map`ing the identity function does nothing.
The full category theory definition requires a bit more exposition than just thinking of things as sets and functions. In particular you need to talk about two levels of mappings: mappings between categories, which are functors, and mappings between functors themselves, which are natural transformations. A monad is then a functor from a category to itself with two associated natural transformations. If the functor and natural transformations are taken as objects and arrows/morphisms in a category itself, then it forms a monoid. This is why we can also think of a monad as a monoid.
This sort of "category-stacking" where mappings between categories are treated as categories themselves where we can then further discuss another level of mapping between them, is the core of category theory.
Re: Monads are monoids in the category of endofunctors
#28Functional programming is subject to an enormous amount of gatekeeping. Kudos to the author for pushing that gate wide open.
Re: Monads are monoids in the category of endofunctors
#29https://www.slideshare.net/ScottWlaschin/railway-oriented-pr...
https://fsharpforfunandprofit.com/posts/recipe-part2/ for a text version
https://fsharpforfunandprofit.com/rop/ for the "hub" that discusses how this isn't really a monad tutorial but hints at how you can go deeper - and if you read this before you read the OP you can see how the meta-puzzle pieces fit together!
At the highest level, this helped me see that monads are really just Level 2 of "things that help you glue things together that weren't meant to be glued together (particularly if those things emit changes to some external state.)" And that's exactly what the railway/error-handling analogy brilliantly shows. You've probably written almost-monadic things yourself, you just don't know it!
Re: Monads are monoids in the category of endofunctors
#30Here is a correct explanation: https://stackoverflow.com/a/3870310