Functional Programming @programming.dev lysdexic @programming.dev 8mo ago

Monad (functional programming) - Wikipedia

en.wikipedia.org Monad (functional programming) - Wikipedia

11 comments

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.
- https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/
- Have an upvote. Thanks for trying. Interesting to me also, but yeah, its dead in here.
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.
- @demesisx @lysdexic No safety issues mentioned around ReaderT. The speaker was talking about how stacking monad transformers mtl-style can generate unnecessary closures that GHC can't optimise away.
  
  Thanks for the clarification.
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] K is a lax 2-functor from the terminal bicategory 1 to K: the unique object * of 1 is sent to the object a, the morphism 1 becomes [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 C tend to be expressible as endomorphisms in 2-categories where C is an object! Since this latter condition is typically trivial, it follows that endofunctors on C typically carry monads (and that any counterexamples depend on the structure of C and choice of 2-category.)

11 comments