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

2 Usage

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

.

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.

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.

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