Kim-Ee Yeoh a.biurvOir4 at asuhan.com
Thu Aug 16 12:55:11 EDT 2007


Paul Hudak wrote:
>
> [I]n the one-of-many ways that I view monads, a monad is just a high-order
> function that abstracts away function composition.  In particular, if I
> have an action f, and an action g, I can think of them as recipes, because
> I can combine them via f >>= g.  It's only after I combine all of my
> actions together that I apply the result to my input (via "run").
>
> Well, that's just like function composition.  In particular, if I have a
> function f, and a function g, I can think of them as recipes, because I
> can combine them via f . g.
>

First a nitpick:

co/bind generalizes function /application/, i.e. flip (\$).

Generalized function /composition/ on the other hand has a different
type. For instance, in the case of monads it's

\begin{code}

(<.>) :: Monad m => (a -> m b) -> (c -> m a) -> (c -> m b)
(<.>) f g c = (g c) >>= f

\end{code}

Function (<.>) is flip (>>>) in the instance of Monad m => Arrow
(Kleisli m). (For a moment there I couldn't find it in the haskell
libs. Would be nice if Hoogle could read instances such as these. I
must not be using Hoogle right, I couldn't even locate (>>=) by
type signature.)

Returning to the main point, like you and Dan P, I also have my
reservations explaining a monadified value as a recipe, although
for arguably different reasons. It's too chef-centric for me, to
continue with the original analogy. I have an allergic reaction to
"run" functions, at least what they connote. I claim that in
what you want to write.

Or put another way, you just program like before except lifting