[Haskell-cafe] Re: Re: Explaining monads

[Dan Piponi]

On 8/13/07, Benjamin Franksen <benjamin.franksen at bessy.de> wrote:

> Ok, I admit defeat now ;-) Monads in general /allow/ sequencing of (certain)
> effects, but it is not necessary for a monad to do so.

I'm sure I said that 300 or so posts ago :-)

Here's an example that might help make some of this explicit.

Suppose I have a function f :: a -> b -> c.
Now suppose I have some values "in a monad":
x :: m a
y :: m b

How do I lift f so I can apply it to x and y and get a value of type m
c? Obviously I can't just write f x y.

There's an obvious solution that comes to mind:

do
  x' <- x
  y' <- y
  return $ f x' y'

But there's another solution:

do
  y' <- y
  x' <- x
  return $ f x' y'

So in order to lift f I was forced to make an explicit decision about
the order in which I wanted to process x and y. (I think of >>= as a
kind of bottleneck that forces you to compute the arguments to f one
at a time in a particular order - but there are already too many
metaphors flying around so maybe you should ignore that.) Information
about that decision now becomes available to the monad's
implementation.

If you want, you can use this information to implement 'sequencing'
(whatever that means). But you're also free to ignore it. If you do
ignore it then you have a commutative monad, with Reader being the
best known example.

It's just like ordinary monoids. The very act of writing x*y imposes
an order on x and y. You can use this to define binary operators that
can make use of this ordering. But the most familiar monoid operators
(addition and multiplication of course) are commutative and order
doesn't matter. It'd be cool to have a notation that didn't force you
to put one argument or the other first. (Well, I know of one, but it's
a bit wacky: http://www.lawsofform.org/interpretations.html)
--
Dan