[Haskell-beginners] Re: Thinking about monads
Ertugrul Soeylemez
es at ertes.de
Sun Apr 12 05:03:01 EDT 2009
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/
More information about the Beginners
mailing list