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.
