[Haskell-cafe] Monads: external questions

[John Lato]

A fairly short answer for now, that doesn't address everything.

I don't think monads necessarily change the way one things about a problem.
I personally think of a monad as a way to structure a computation.  There's
a bit of a hierarchy:
  1. functions model a computation from inputs to an output.
  2. Applicative functors model a computation from inputs to an output
within some type of fancy context.  The computation can depend on the
context, but it cannot change the context at all.
  3. Monads allow the computation to affect the context.

That's why a monad is a good model for mutable state: it's a very simple
structure that allows for the computation to mutate the state (context).
Mutable state itself is a decent model for IO.

In practice there are other common users of monads.  Modeling coroutines is
probably one of the most useful, although perhaps it's not used as widely
as it could be.

Formerly one of the biggest pitfalls was using a monad when an Applicative
would be sufficient.  Hopefully the AMP will help with this in the future.
Otherwise, I think generally monads are a good model when their power is
required.
 On Oct 25, 2014 4:24 PM, "Jeffrey Brown" <jeffbrown.the at gmail.com> wrote:

> 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.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141025/a8028372/attachment.html>