# Talk:Monad

### From HaskellWiki

(A small bit of Functor/Monad correspondence) |
|||

(3 intermediate revisions by one user not shown) | |||

Line 7: | Line 7: | ||

Usually, I stay away from using liftM, since it's identical to fmap, only |
Usually, I stay away from using liftM, since it's identical to fmap, only |
||

− | confined t Monads, as 'ap' is to (<*>). However, the other liftMn functions are a nice generalization of the zipWithn family to Monads. The benefits of that, I'll leave for another discussion. |
+ | confined to Monads, as 'ap' is to (<*>). However, the other liftMn functions are a nice generalization of the zipWithn family to Monads. The benefits of that, I'll leave for another discussion. |

[[User:BMeph|BMeph]] 04:30, 11 March 2008 (UTC) |
[[User:BMeph|BMeph]] 04:30, 11 March 2008 (UTC) |
||

+ | |||

+ | Hope my edit is OK, about Monads as composable computation descriptions whose essence is separation of composition timeline from the run time. That's my hard won insight anyhow. [[User:WillNess|WillNess]] 12:22, 9 June 2010 (UTC) |

## Latest revision as of 12:51, 11 January 2011

About some of that "Functor/Applicative/Monad" business, a little equivalence formula that's worked well for me goes like so:

Just to refresh, (=<<) is the reversed bind. Also, 'ap' is the Monad version of the applicative operator, (<*>) - see the Control.Applicative module for more help.

Usually, I stay away from using liftM, since it's identical to fmap, only confined to Monads, as 'ap' is to (<*>). However, the other liftMn functions are a nice generalization of the zipWithn family to Monads. The benefits of that, I'll leave for another discussion.

BMeph 04:30, 11 March 2008 (UTC)

Hope my edit is OK, about Monads as composable computation descriptions whose essence is separation of composition timeline from the run time. That's my hard won insight anyhow. WillNess 12:22, 9 June 2010 (UTC)