# Difference between revisions of "Applicative functor"

(usage of applicative functors) |
(ZipList) |
||

Line 109: | Line 109: | ||

== 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. 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. |
* 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. |
||

## Revision as of 12:15, 10 July 2009

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

.

## Contents

## 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.

## 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`

.

## 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.

## How to switch from monads

- Start using
`liftM`

,`liftM2`

, etc or`ap`

where you can, in place of`do`

/`(>>=)`

. - 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).

## See also

- The blog article The basics of applicative functors, put to practical work