Difference between revisions of "Talk:Monad"
| (One intermediate revision by the same user not shown) | |||
| Line 12: | Line 12: | ||
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) |
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) |
||
| − | |||
| − | : Blessed be He that separateth between the pure and the impure. :) [[User:WillNess|WillNess]] 10:28, 16 July 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:
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)