Live data from Hacker News

Monads are monoids in the category of endofunctors

sambernheim.com

21–30 of 241 posts

Re: Monads are monoids in the category of endofunctors

#24
This post is very wrong. Being a monoid in the category of endofunctors means something very different from being a monoid in the normal sense (they're related in a category-theoretic way, but the similarity is at a very abstract level). Simple sequences have a lot of structure which mean they are a lot of different things; it is true that sequences are all of monads, functors, and monoids, but the latter structure is unrelated to the former.

Contrary 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

#25
post #5

Wait, 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'.

Which means something completely different from the use of "monadic" here.

Re: Monads are monoids in the category of endofunctors

#26
post #5

Wait, 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?

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

#27
This article is playing fast and loose and I think gives a false understanding of what functors and monads are.

In 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

#28
post #3

Functional programming is subject to an enormous amount of gatekeeping. Kudos to the author for pushing that gate wide open.

Author is completely wrong, and as such is a perfect demonstration of why that "gatekeeping" (actually just being precise and correct) is necessary.

Re: Monads are monoids in the category of endofunctors

#29
If you're looking for a not-quite-monad tutorial that answers real-world programming problems, blows the gates off monad-notation gatekeeping, and pokes good-natured fun at the OP title, I highly recommend Railway Oriented Programming:

https://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!

Post reply on HN