Difference between revisions of "Applicative functor"
m (fix link) 
(→Usage: Improved formatting) 

Line 65:  Line 65:  
</haskell> 
</haskell> 

you can combine them in the following ways with the same result of type <hask>f c</hask>: 
you can combine them in the following ways with the same result of type <hask>f c</hask>: 

+  * <hask>pure f <*> a <*> b</hask> 

−  <haskell> 

−  +  * <hask>liftA2 f a b</hask> 

−  
−  liftA2 f a b 

−  </haskell> 

But how to cope with <hask>let</hask> and sharing in the presence of effects? 
But how to cope with <hask>let</hask> and sharing in the presence of effects? 

Line 94:  Line 91:  
</haskell> 
</haskell> 

runs the effect of <hask>fy</hask> twice. 
runs the effect of <hask>fy</hask> twice. 

−  E.g. if <hask>fy</hask> writes something to the terminal then <hask>fh <*> fy <*> fy</hask> writes twice. 
+  E.g. if <hask>fy</hask> writes something to the terminal then <hask>fh <*> fy <*> fy</hask> writes twice. This could be intended, but how can we achieve, that the effect is run only once and the result is used twice? 
−  This could be intended, but how can we achieve, 

−  that the effect is run only once and the result is used twice? 

−  Actually, using the <hask>liftA</hask> commands we can pull results of applicative functors 
+  Actually, using the <hask>liftA</hask> commands we can pull results of applicative functors into a scope where we can talk exclusively about functor results and not about effects. Note that functor results can also be functions. This scope is simply a function, which contains the code that we used in the nonfunctorial setting. 
−  into a scope where we can talk exclusively about functor results and not about effects. 

−  Note that functor results can also be functions. 

−  This scope is simply a function, which contains the code that we used in the nonfunctorial setting. 

<haskell> 
<haskell> 

liftA3 
liftA3 
Revision as of 10:57, 5 July 2017
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 some 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 HaskellCafe:
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.
Usage
If you have the variables
f :: a > b > c
a :: f a
b :: f b
you can combine them in the following ways with the same result of type f c
:
pure f <*> a <*> b
liftA2 f a b
But how to cope with let
and sharing in the presence of effects?
Consider the nonfunctorial expression:
x :: x
g :: x > y
h :: y > y > z
let y = g x
in h y y
Very simple. Now we like to generalize this to
fx :: f x
fg :: f (x > y)
fh :: f (y > y > z)
However, we note that
let fy = fg <*> fx
in fh <*> fy <*> fy
runs the effect of fy
twice.
E.g. if fy
writes something to the terminal then fh <*> fy <*> fy
writes twice. This could be intended, but how can we achieve, that the effect is run only once and the result is used twice?
Actually, using the liftA
commands we can pull results of applicative functors into a scope where we can talk exclusively about functor results and not about effects. Note that functor results can also be functions. This scope is simply a function, which contains the code that we used in the nonfunctorial setting.
liftA3
(\x g h > let y = g x in h y y)
fx fg fh
The order of effects is entirely determined by the order of arguments to liftA3
.
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. TheZipList
is an applicative functor on lists, whereliftA2
is implemented byzipWith
. It is a typical example of an applicative functor that is not a monad.  Programming with
Applicative
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 transformers
From the Monad Transformer Library we are used to have two flavours of every monad:
A base monad like State
and a transformer variant StateT
.
In the transformers package we even have only monad transformers
except the Identity
monad.
So where are applicative transformers?
The answer is, that we do not need special transformers for applicative functors
since they can be combined in a generic way.
h :: f (g (a > b))
a :: f (g a)
liftA2 (<*>) h a :: f (g b)
That is liftA2 (<*>)
is essentially the definition for <*>
for the composition of the functors f
and g
.
This is implemented in the TypeCompose library as type constructor O
and in transformers library in module Data.Functor.Compose
.
The first one needs a lot of type extensions, whereas the second one is entirely Haskell 98.
It can be useful to use the applicative composition even when you have a monad transformer at hand.
In the example above f
might be Writer (Sum Int)
that is used for counting the number of involved applicative actions.
Since in an applicative functor the number of run actions is independent from interim results,
the writer can count the actions at compile time.
How to switch from monads
 Start using
liftM
,liftM2
, etc orap
where you can, in place ofdo
/(>>=)
. You will often encounter code like
do x < fx
y < fy
return (g x y)
 It can be rewritten to
liftM2 g fx fy
. In general, whenever the choice or construction of monadic actions does not depend on the outcomes of previous monadic actions, then it should be possible to rewrite everything withliftM
.
 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).
Alternative terms
Applicative functors were introduced by several people under different names:
 Ross Paterson called them Sequence
 Conor McBride called them Idiom
 The same kind of structure is used in the UU ParsingCombinators.