[Haskell-cafe] Explaining monads

[Kim-Ee Yeoh]

Ronald Guida wrote:
> 
> Here's my interpretation of the table:
> 
> ----------------------------------------------------------------------
>  Structure   | Subject  |  Action    |  Verb      |  Result
>  ------------+----------+------------+------------+----------
>  function    |  a       |  a->b      |  flip ($)  |  b
>  Functor     |  f a     |  a->b      |  <$>       |  f b
>  Applicative |  f a     |  f (a->b)  |  flip <*>  |  f b
>  Monad       |  m a     |  a->m b    |  >>=       |  m b
>  Comonad     |  w a     |  w a->b    |  =>>       |  w b
>  Arrow       |  a b c   |  a c d     |  >>>       |  a b d
> ----------------------------------------------------------------------
> 

This is the first time I've seen <$>. What a pleasing synonym for fmap. To
maintain a similar order of parameters, I think you'd want "flip <$>" up
there.


Ronald Guida wrote:
> 
> ----------------------------------------------------------------------
> Foo       a   = Foo     { runFoo     ::            a     } -- Functor
> State   s a   = State   { runState   ::     s  -> (a, s) } -- Monad
> Context c a   = Context { runContext :: (a, c) ->  a     } -- Comonad
> Thing   s a b = Thing   { runThing   :: (a, s) -> (b, s) } -- Arrow???
> ----------------------------------------------------------------------
> 

I believe there is a way to see all of the above as forms of "generalized
application" although not in the way presented here. (I thank Brian for
pointing to the possibility of a unified treatment in the first place.) 

A point in common among your run* functions is that you can always observe
the instance of type (a) in (m a :: Monad a). But monads are equipped with
(return :: a -> m a), not (coreturn :: m a -> a). Your 2nd table is more
about comonads, at least the coreturn aspect, than about whatever unity
you're hoping to achieve. There's more about coreturn here:
http://www.haskell.org/pipermail/haskell-cafe/2007-August/030153.html

So we need to explore "generalized application" without being too explicit
about "unwrapping" monads nor "wrapping" comonads. Why? Because being too
explicit invariably locks us into one particular instantiation and the
generalization goes poof! Think of all the otherwise rich and creative
papers written on the IO monad and its innards. 

The instances of monads I've seen are in themselves too sexy (probabilistic
modelling! digital circuit simulation! IO! concurrency!) that they end up
overwhelming the essence of monadism pregnant within. Better to start with
something boring. Like the Maybe monad.

Feck heh, "The essence of monadism pregnant within." Another fine title for
another monad tutorial.

-- 
View this message in context: http://www.nabble.com/Explaining-monads-tf4244948.html#a12103564
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.