Applicative functor
From HaskellWiki
(Difference between revisions)
(Some advantages of Applicative) |
(sections ; how to switch from monads) |
||
| Line 20: | Line 20: | ||
--> | --> | ||
| - | Some advantages of | + | == Some advantages of applicative functors == |
* Code that uses only on the <hask>Applicative</hask> interface are more general than ones uses the <hask>Monad</hask> interface, because there are more applicative functors than monads. | * Code that uses only on the <hask>Applicative</hask> interface are more general than ones uses the <hask>Monad</hask> interface, because there are more applicative functors than monads. | ||
* Programming with <hask>Applicative</hask> has a more applicative/functional feel. Especially for newbies, it may encourage functional style even when programming with effects. Monad programming with <hask>do</hask> notation encourages a more sequential & imperative style. | * Programming with <hask>Applicative</hask> has a more applicative/functional feel. Especially for newbies, it may encourage functional style even when programming with effects. Monad programming with <hask>do</hask> notation encourages a more sequential & imperative style. | ||
| + | |||
| + | == How to switch from monads == | ||
| + | |||
| + | * Start using <hask>liftM</hask>, <hask>liftM2</hask>, etc or <hask>ap</hask> where you can, in place of <hask>do</hask>/<hask>(>>=)</hask>. | ||
| + | * When you notice you're ''only'' using those monad methods, then import <hask>Control.Applicative</hask> and replace<hask>return</hask> with <hask>pure</hask>, <hask>liftM</hask> with <hask>(<$>)</hask> (or <hask>fmap</hask> or <hask>liftA</hask>), <hask>liftM2</hask> with <hask>liftA2</hask>, etc, and <hask>ap</hask> with <hask>(<*>)</hask>. If your function signature was <hask>Monad m => ...</hask>, change to <hask>Applicative m => ...</hask> (and maybe rename <hask>m</hask> to <hask>f</hask> or whatever). | ||
Revision as of 08:23, 5 November 2007
An applicative functor has more structure than a functor but less than a monad. See the Haddock docs for <div class="inline-code">Control.Applicative
It has turned out that many applications do not require monad functionality but only those of applicative functors. Monads allow you to run actions depending on the outcomes of earlier actions.
do text <- getLine if null text then putStrLn "You refuse to enter something?" else putStrLn ("You entered " ++ text)
This is obviously necessary is some cases, but in other cases it is disadvantageous.
1 Some advantages of applicative functors
- Code that uses only on the interface are more general than ones uses theApplicativeinterface, because there are more applicative functors than monads.Monad
- Programming with has a more applicative/functional feel. Especially for newbies, it may encourage functional style even when programming with effects. Monad programming withApplicativenotation encourages a more sequential & imperative style.do
2 How to switch from monads
- Start using ,liftM, etc orliftM2where you can, in place ofap/do.(>>=)
- When you notice you're only using those monad methods, then import and replaceControl.Applicativewithreturn,purewithliftM(or(<$>)orfmap),liftAwithliftM2, etc, andliftA2withap. If your function signature was(<*>), change toMonad m => ...(and maybe renameApplicative m => ...tomor whatever).f
