[Haskell-cafe] Monad Description For Imperative Programmer

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,
monads are no more about (only) IO/sequencing than fmap is about (only)
lists. To learn about monadic imperative programming there are excellent
places for doing so, but to learn about co/monads qua co/monads well, too

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
Have Invented Co/Monads Too.

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
> IO monad.

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
  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
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

More information about the Haskell-Cafe mailing list