As opposed to the internal logic of monads, how they work, I hope to start a discussion about their external logic: how and why to use monads.

design

------

How do monads change the way one   

* thinks about a problem?   

* structures data?   

* refactors?   

* tests?

Should I always be giving the monads a lot of cognitive bandwidth, because they reorder the way everything should be, or is it an investment with a high initial cognitive cost but requiring little maintenance thereafter?

                                                    

what is their common framework?

-------------------------------

Monads let data reach farther than it otherwise would. Subjectively, they feel like a controlled way of violating encapsulation.

Are there other, deeper or more specific, commonalities that explain why monads are a good way to implement exceptions, output, state, and perhaps other services?

varieties

---------

In practice, are all monads either for exceptions, state or output? If not, what other goals are monads well suited to?

How should multiple contexts coexist? What's a simple Haskell program that uses more than one kind of monad in the same scope? Should, say, output and state be nestled in parallel into a three-attribute monad (the third variable being the type variable), or would it instead be better to create separate output and state monads? If each context should have a separate monad, is it a good idea to nest them, or somehow otherwise let them overlap, within a particular function or scope?

temptations to err

------------------

I have a vague sense that a common pitfall is to use monads to do things in a procedural way that eliminates the benefits of a functional language, but I'm not sure I would recognize it if I were making that error. I feel like I could learn from a comparison of code that works and uses monads badly to code that does better.