Applicative functor

From HaskellWiki

Revision as of 21:16, 1 November 2009

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)

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.

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

2 Usage

If you have the variables

f :: a -> b -> c
a :: f a
b :: f b

pure f <*> a <*> b
 
liftA2 f a b

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

This could be intended, but how can we achieve, that the effect is run only once and the result is used twice?

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

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.

4 Applicative transfomers

From the Monad Transformer Library we are used to have two flavours of every monad:

In the transformers package we even have only monad transformers

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)

However the library needs a lot of type extensions although applicative composition itself is entirely Haskell 98.

It can be useful to use the applicative composition even when you have a monad transformer at hand.

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

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

6 See also

• Applicative Programming with Effects
• The blog article The basics of applicative functors, put to practical work

Categories: Glossary | Applicative Functor