Personal tools

Applicative functor

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(sections ; how to switch from monads)
m (fixed link to UU)
 
(13 intermediate revisions by 3 users not shown)
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>].
+
[[Category:Applicative Functor|*]]
  +
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 Control.Applicative].
  +
  +
== 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 10:
 
else putStrLn ("You entered " ++ text)
 
else putStrLn ("You entered " ++ text)
 
</haskell>
 
</haskell>
This is obviously necessary is some cases, but in other cases it is disadvantageous.
+
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 ()
   
In contrast, a monad which handles allocation of resources, that are needed later, is impossible.
+
liftToCleanup :: IO a -> CleanIO a
   
See Haskell-Cafe discussion.
+
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 some 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.
  +
  +
== Usage ==
  +
  +
If you have the variables
  +
<haskell>
  +
f :: a -> b -> c
  +
a :: f a
  +
b :: f b
  +
</haskell>
  +
you can combine them in the following ways with the same result of type <hask>f c</hask>:
  +
<haskell>
  +
pure f <*> a <*> b
  +
  +
liftA2 f a b
  +
</haskell>
  +
  +
But how to cope with <hask>let</hask> and sharing in the presence of effects?
  +
Consider the non-functorial expression:
  +
<haskell>
  +
x :: x
  +
g :: x -> y
  +
h :: y -> y -> z
  +
  +
let y = g x
  +
in h y y
  +
</haskell>
  +
Very simple.
  +
Now we like to generalize this to
  +
<haskell>
  +
fx :: f x
  +
fg :: f (x -> y)
  +
fh :: f (y -> y -> z)
  +
</haskell>
  +
However, we note that
  +
<haskell>
  +
let fy = fg <*> fx
  +
in fh <*> fy <*> fy
  +
</haskell>
  +
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.
  +
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
  +
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 non-functorial setting.
  +
<haskell>
  +
liftA3
  +
(\x g h -> let y = g x in h y y)
  +
fx fg fh
  +
</haskell>
  +
The order of effects is entirely determined by the order of arguments to <hask>liftA3</hask>.
   
 
== 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.
+
* 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.
+
* 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. The <hask>ZipList</hask> is an applicative functor on lists, where <hask>liftA2</hask> is implemented by <hask>zipWith</hask>. It is a typical example of an applicative functor that is not a monad.
  +
* 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.
  +
  +
== Applicative transfomers ==
  +
  +
From the [[Monad Transformer Library]] we are used to have two flavours of every monad:
  +
A base monad like <hask>State</hask> and a transformer variant <hask>StateT</hask>.
  +
In the [http://hackage.haskell.org/package/transformers/ transformers] package we even have only monad transformers
  +
except the <hask>Identity</hask> 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.
  +
<haskell>
  +
h :: f (g (a -> b))
  +
a :: f (g a)
  +
  +
liftA2 (<*>) h a :: f (g b)
  +
</haskell>
  +
That is <hask>liftA2 (<*>)</hask> is essentially the definition for <hask><*></hask>
  +
for the composition of the functors <hask>f</hask> and <hask>g</hask>.
  +
This is implemented in the {{HackagePackage|id=TypeCompose}} library as type constructor <hask>O</hask> and in {{HackagePackage|id=transformers}} library in module <hask>Data.Functor.Compose</hask>.
  +
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 <hask>f</hask> might be <hask>Writer (Sum Int)</hask>
  +
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 ==
 
== 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>.
+
* Start using <hask>liftM</hask>, <hask>liftM2</hask>, etc or <hask>ap</hask> where you can, in place of <hask>do</hask>/<hask>(>>=)</hask>. You will often encounter code like
  +
<haskell>
  +
do x <- fx
  +
y <- fy
  +
return (g x y)
  +
</haskell>
  +
:It can be rewritten to <hask>liftM2 g fx fy</hask>. 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 with <hask>liftM</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).
 
* 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).
  +
  +
  +
== Alternative terms ==
  +
  +
Applicative functors were introduced by several people under different names:
  +
* Ross Paterson called them [http://www.haskell.org/arrows/arrows/Control.Sequence.html Sequence]
  +
* Conor McBride called them [http://www.haskell.org/pipermail/haskell/2004-July/014315.html Idiom]
  +
* The same kind of structure is used in the [http://www.cs.uu.nl/wiki/Center/UtrechtParserCombinators UU Parsing-Combinators].
  +
  +
  +
== See also ==
  +
  +
* [http://www.soi.city.ac.uk/~ross/papers/Applicative.html Applicative Programming with Effects]
  +
* The blog article [http://www.serpentine.com/blog/2008/02/06/the-basics-of-applicative-functors-put-to-practical-work/ The basics of applicative functors, put to practical work]

Latest revision as of 05:53, 17 December 2011

An applicative functor has more structure than a functor but less than a monad. See the Haddock docs for Control.Applicative.

Contents

[edit] 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)
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 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.

[edit] 2 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 non-functorial 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 non-functorial 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
.

[edit] 3 Some advantages of applicative functors

  • Code that uses only on the
    Applicative
    interface are more general than ones uses the
    Monad
    interface, because there are more applicative functors than monads. The
    ZipList
    is an applicative functor on lists, where
    liftA2
    is implemented by
    zipWith
    . 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.

[edit] 4 Applicative transfomers

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.

[edit] 5 How to switch from monads

  • Start using
    liftM
    ,
    liftM2
    , etc or
    ap
    where you can, in place of
    do
    /
    (>>=)
    . 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 with
liftM
.
  • When you notice you're only using those monad methods, then import
    Control.Applicative
    and replace
    return
    with
    pure
    ,
    liftM
    with
    (<$>)
    (or
    fmap
    or
    liftA
    ),
    liftM2
    with
    liftA2
    , etc, and
    ap
    with
    (<*>)
    . If your function signature was
    Monad m => ...
    , change to
    Applicative m => ...
    (and maybe rename
    m
    to
    f
    or whatever).


[edit] 6 Alternative terms

Applicative functors were introduced by several people under different names:


[edit] 7 See also