Difference between revisions of "Talk:Monad"
(A small bit of Functor/Monad correspondence) |
|||
| 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 |
+ | 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) |
||
Revision as of 12:22, 9 June 2010
About some of that "Functor/Applicative/Monad" business, a little equivalence formula that's worked well for me goes like so:
ap (return f) x == (return . f) =<< x == liftM f x == fmap f x
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)