Michael Mossey
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/