Applicative functor: Difference between revisions
(sections ; how to switch from monads) |
(automatic cleanup with monad, automatic initialization with applicative functor) |
||
Line 1: | Line 1: | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
An applicative functor has more structure than a [[functor]] but less than a [[monad]]. See the Haddock docs for [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html <hask>Control.Applicative</hask>]. | An applicative functor has more structure than a [[functor]] but less than a [[monad]]. See the Haddock docs for [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html <hask>Control.Applicative</hask>]. | ||
== Example == | |||
It has turned out that many applications do not require monad functionality but only those of applicative functors. | It has turned out that many applications do not require monad functionality but only those of applicative functors. | ||
Line 10: | Line 12: | ||
else putStrLn ("You entered " ++ text) | else putStrLn ("You entered " ++ text) | ||
</haskell> | </haskell> | ||
This is obviously necessary | 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 | Consider an extended IO monad which handles automated closing of allocated resources. | ||
This is possible with a monad. | This is possible with a monad. | ||
<haskell> | |||
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) | |||
</haskell> | |||
The (fictive) functions <hask>openDialog</hask> and <hask>openWindow</hask> | |||
could not only open dialogs and windows but could also register come cleanup routine in the <hask>CleanIO</hask>. | |||
<hask> runAndCleanup </hask> would first run the opening actions and afterwards the required cleanup actions. | |||
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: | |||
[http://www.haskell.org/pipermail/haskell-cafe/2007-June/027517.html Practical Haskell Question]) | |||
This is impossible in the monadic framework. | |||
Consider the example above where the choice between <hask>openDialog</hask> and <hask>openWindow</hask> | |||
depends on the outcome of <hask> getLine </hask>. | |||
You cannot run initialization code for either <hask>openDialog</hask> or <hask>openWindow</hask>, | |||
because you do not know which one will be called before executing <hask> getLine </hask>. | |||
If you eliminate this dependency, you end up in an applicative functor | |||
and there you can do the initialization trick. | |||
You could write | |||
<haskell> | |||
initializeAndRun $ | |||
liftA2 | |||
(liftToInit getLine) | |||
(writeToWindow "You requested to open a window") | |||
</haskell> | |||
where <hask> writeToWindow </hask> registers an initialization routine which opens the window. | |||
== Some advantages of applicative functors == | == Some advantages of applicative functors == |
Revision as of 14:35, 5 November 2007
An applicative functor has more structure than a functor but less than a monad. See the Haddock docs for Control.Applicative
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)
The (fictive) functions openDialog
and openWindow
could not only open dialogs and windows but could also register come cleanup routine in the CleanIO
.
runAndCleanup
would first run the opening actions and afterwards the required cleanup actions.
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.
Consider the example above where the choice between openDialog
and openWindow
depends on the outcome of getLine
.
You cannot run initialization code for either openDialog
or openWindow
,
because you do not know which one will be called before executing getLine
.
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")
where writeToWindow
registers an initialization routine which opens the window.
Some advantages of applicative functors
- Code that uses only on the
Applicative
interface are more general than ones uses theMonad
interface, because there are more applicative functors than monads. - Programming with
Applicative
has a more applicative/functional feel. Especially for newbies, it may encourage functional style even when programming with effects. Monad programming withdo
notation encourages a more sequential & imperative style.
How to switch from monads
- Start using
liftM
,liftM2
, etc orap
where you can, in place ofdo
/(>>=)
. - When you notice you're only using those monad methods, then import
Control.Applicative
and replacereturn
withpure
,liftM
with(<$>)
(orfmap
orliftA
),liftM2
withliftA2
, etc, andap
with(<*>)
. If your function signature wasMonad m => ...
, change toApplicative m => ...
(and maybe renamem
tof
or whatever).