[Haskell-beginners] Re: Thinking about monads

[Ertugrul Soeylemez]

Michael Mossey <mpm at alumni.caltech.edu> wrote:

> I'm getting a better grasp on monads, I think. My original problem, I
> think, was that I was still thinking imperatively. So when I saw this:
>
> class Monad m where
>
>     (>>=) :: m a -> (a -> m b) -> m b
>
> I didn't understand the "big deal". I thought, okay so you "do" something with the 
> function (a -> m b) and you "arrive" at m b.  [...]

Think of f being a computation, in which something is missing.  It takes
this something through a parameter.  So f is actually a function, which
takes a value and results in a computation.  Another intuition:  f is a
parametric computation.  Now if c0 is a computation, then

  c0 >>= f

is another computation built by feeding the result of c0 to f.  More
graphically you've plugged the result cable of c0 to the input port of
f.

As a real world example, consider a computation, which prints a value x:

  print x

That x has to come from somewhere, so this should actually be a function
of some value x:

  \x -> print x

If that x should come from another computation, then (>>=) comes into
play.  You can pass the result of one computation to the above one.  For
example, if x comes from the result of getChar, you can write:

  getChar >>= \x -> print x

or simply:

  getChar >>= print

Now to the less specific case.  Look at the type of (>>=):

  (>>=) :: m a -> (a -> m b) -> m b

The left parameter of (>>=) is the source computation, which results in
something of type a.  The right parameter is a parametric computation,
which results in something of type b, but depends on something of type
a.  The result of (>>=) is a computation constructed by feeding the
result of the left computation as the parameter to the right
computation.

I hope, this helped.


Greets,
Ertugrul.


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/