On the latest Haskell interlude podcast, the guest was talking about how using the ReaderT monad specifically introduces safety issues. My ears perked up because I’m right in the middle of leaning on it heavily in one of my Haskell projects.
Thanks for the clarification.
I’ve submitted this link because the topic is interesting to me, and [email protected] is practically dead, with the last post dating back over 10 days.
For those who are down voting the contribution, be my guest and do better: submit interesting content.
Lemmy has a few perpetually online perpetual assholes that down vote anything they see - give a post a few hours and you’ll see the reasonable people show up.
Honestly, I don’t mind the downvotes. What puzzles me is how some people feel strongly enough about a topic to subscribe to a community, but still feel compelled to slap down contributions in a time nothing is being submitted, as if seeing no new posts is better than seeing a post that might not tickle their fancy.
It’s the difference between building up and tearing down.
Have an upvote. Thanks for trying. Interesting to me also, but yeah, its dead in here.
A monad is just a monoid in the category of endofunctors, what’s the problem?
I’ve recently come to appreciate monads as 2-arrows from the terminal object in a 2-category; quoting nLab:
… a monad in [a category]
Kis a lax 2-functor from the terminal bicategory1toK: the unique object*of1is sent to the objecta, the morphism1becomes [the endomorphism]t, and [the unit]ηand [the join]μarise from the coherent 2-cells expressing lax functoriality.This is a nifty demystification of the data of a monad. Why do endofunctors tend to carry monads? Because endofunctors on categories
Ctend to be expressible as endomorphisms in 2-categories whereCis an object! Since this latter condition is typically trivial, it follows that endofunctors onCtypically carry monads (and that any counterexamples depend on the structure ofCand choice of 2-category.)
