Personal tools

Applicative functor

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m (typo fixed: come --> some)
(Added the "See also" section, with a link to a blog article)
Line 64: Line 64:
 
* 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>.
 
* 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).
  +
  +
  +
== See also ==
  +
  +
* 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]

Revision as of 11:54, 7 February 2009

An applicative functor has more structure than a functor but less than a monad. See the Haddock docs for <div class="inline-code">
Control.Applicative
</div>
.

Contents

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.


2 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.
  • 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.

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


4 See also