# Applicative functor

### From HaskellWiki

(do notation link) |
m |
||

Line 58: | Line 58: | ||

== Some advantages of applicative functors == | == 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. | + | * 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 [[Do notation considered harmful|do notation]] encourages a more sequential & imperative style. |

− | Monad programming with [[Do notation considered harmful|do notation]] encourages a more sequential & imperative style. | + | |

== How to switch from monads == | == How to switch from monads == |

## Revision as of 14:38, 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">## 1 Example

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 in some cases, but in other cases it is disadvantageous.

Consider an extended IO monad which handles automated closing of allocated resources. This is possible with a monad.

openDialog, openWindow :: String -> CleanIO () liftToCleanup :: IO a -> CleanIO a runAndCleanup :: CleanIO a -> IO a runAndCleanup $ do text <- liftToCleanup getLine if null text then openDialog "You refuse to enter something?" else openWindow ("You entered " ++ text)

I.e. if the dialog was opened, the dialog must be closed, but not the window. That is, the cleanup procedure depends on the outcomes of earlier actions.

Now consider the slightly different task, where functions shall register *initialization* routines
that shall be run before the actual action takes place.
(See the original discussion started by Michael T. Richter in Haskell-Cafe:
Practical Haskell Question)
This is impossible in the monadic framework.

If you eliminate this dependency, you end up in an applicative functor and there you can do the initialization trick. You could write

initializeAndRun $ liftA2 (liftToInit getLine) (writeToWindow "You requested to open a window")

## 2 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 with do notation encourages a more sequential & imperative style.Applicative

## 3 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 importand replaceControl.Applicativewithreturn,purewithliftM(or(<$>)orfmap),liftAwithliftM2, etc, andliftA2withap. If your function signature was(<*>), change toMonad m => ...(and maybe renameApplicative m => ...tomor whatever).f