Kim-Ee Yeoh a.biurvOir4 at asuhan.com
Wed Aug 8 11:01:13 EDT 2007

```
Seth Gordon wrote:
>
> Functors are a generalization from lists to "things that can be mapped
> over" in general, and then monads are a generalization of functors.
>

Way to go! That way lies true co/monadic enlightenment. Put another way,

So here's my co/monad tutorial, or at least the barest outline of one. I
guess that almost everyone can "get" fmap :: (a -> b) -> (m a -> m b) if
only they got a good workout at it. So let's do lists, then trees, then your
favorite exponential types, say parsers. Howsoever it's done, be sure to get
a good grip on fmap.

Next introduce flip (>>=) :: (a -> m b) -> (m a -> m b) as a left-sided
fmap. Thinking what it means to lift just one side "nicely" should motivate
the return function and monadic laws. Here "nicely" is in the sense that
fmap lifts "nicely."

Of course the classy way of figuring out one-sided fmap's is to contemplate
both flip (>>=) and (comonadic) coextension :: (m a -> b) -> (m a -> m b) at
the same time.

This is my preferred approach to a co/monad tutorial. For sure, You Could

Seth Gordon wrote:
>
> Haskell solves the "how can I do I/O in a pure functional language"
> problem by *turning the world inside-out*.  Instead of taking data from
> the mutable outside world, using functions to manipulate it, and
> depositing results back into that world, you put your functions into the
>

But (the illusion of) taking data out from the real world, manipulating it,
and then putting it back is exactly what the monadic-do syntax sugar
accomplishes:
do
x <- inputFromRealWorld
let y = manipulateIt x
return y

You could use (fmap manipulateIt) to "put" it into the IO monad as you
describe, but monadic-do is by far the more common approach.

--
View this message in context: http://www.nabble.com/Monad-Description-For-Imperative-Programmer-tf4198417.html#a12055086

```