[Haskell-cafe] Explaining monads

[Kim-Ee Yeoh]

Brian Brunswick-5 wrote:
> 
>                   g          f       ???          g ??? f
> 
> application      a         a->b      flip ($)     b
> monad bind       m a       a->m b    >>=          m b
> comonad cobind   w a       w a->b    =>>          w b
> arrow            arr a b   arr b c   >>>          arr a c
> 

Fmap's missing: m a, a->b, flip fmap, m b. You might want to throw in
Applicative there too: m a, m (a->b), flip (<*>), m b.

Snipped: Arguments for monads being the best of the M-C-A trinity.

While I can share your enthusiasm over certain insights you've discovered
about monads, I think you'll find that each of those structures have their
privileged place in your code. You say "monads are somehow the /simplest/
way of adding general control structure on top of single values." Well sure,
for specific implicit parameters of ?simplest, ?general, and
?controlStructure. It's like saying lists are better than arrays and tuples.

Monads are undoubtedly more pervasive, and that could be because there
aren't as many arrow and comonad tutorials, atomic ones or otherwise. 


Brian Brunswick-5 wrote:
> 
> Pity the poor comonad, only really suitable for infinite sequences!
> 

Comonads are no more (exclusively) about infinite structures than monads are
(exclusively) about sequencing/imperative programming.

What's so infinite about this (specialization of the so-called Product)
comonad:

instance Comonad ((,) Bool)  where
  -- coreturn :: (Bool, r) -> r
  coreturn (b, r) = r
  -- cobind :: (Bool, r) -> ((Bool, r) -> s) -> (Bool, s)
  coextend u@(b,r) g = (b, g u)

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