Difference between Monad and Applicative in Haskell

by

My favorite example is the “purely applicative Either”. We’ll start by analyzing the base Monad instance for Either

instance Monad (Either e) where
  return = Right
  Left e  >>= _ = Left e
  Right a >>= f = f a

This instance embeds a very natural short-circuiting notion: we proceed from left to right and once a single computation “fails” into the Left then all the rest do as well. There’s also the natural Applicative instance that any Monad has

instance Applicative (Either e) where
  pure  = return
  (<*>) = ap

where ap is nothing more than left-to-right sequencing before a return:

ap :: Monad m => m (a -> b) -> m a -> m b
ap mf ma = do 
  f <- mf
  a <- ma
  return (f a)

Now the trouble with this Either instance comes to light when you’d like to collect error messages which occur anywhere in a computation and somehow produce a summary of errors. This flies in the face of short-circuiting. It also flies in the face of the type of (>>=)

(>>=) :: m a -> (a -> m b) -> m b

If we think of m a as “the past” and m b as “the future” then (>>=) produces the future from the past so long as it can run the “stepper” (a -> m b). This “stepper” demands that the value of a really exists in the future… and this is impossible for Either. Therefore (>>=) demands short-circuiting.

So instead we’ll implement an Applicative instance which cannot have a corresponding Monad.

instance Monoid e => Applicative (Either e) where
  pure = Right

Now the implementation of (<*>) is the special part worth considering carefully. It performs some amount of “short-circuiting” in its first 3 cases, but does something interesting in the fourth.

  Right f <*> Right a = Right (f a)     -- neutral
  Left  e <*> Right _ = Left e          -- short-circuit
  Right _ <*> Left  e = Left e          -- short-circuit
  Left e1 <*> Left e2 = Left (e1 <> e2) -- combine!

Notice again that if we think of the left argument as “the past” and the right argument as “the future” then (<*>) is special compared to (>>=) as it’s allowed to “open up” the future and the past in parallel instead of necessarily needing results from “the past” in order to compute “the future”.

This means, directly, that we can use our purely Applicative Either to collect errors, ignoring Rights if any Lefts exist in the chain

> Right (+1) <*> Left [1] <*> Left [2]
> Left [1,2]

So let’s flip this intuition on its head. What can we not do with a purely applicative Either? Well, since its operation depends upon examining the future prior to running the past, we must be able to determine the structure of the future without depending upon values in the past. In other words, we cannot write

ifA :: Applicative f => f Bool -> f a -> f a -> f a

which satisfies the following equations

ifA (pure True)  t e == t
ifA (pure False) t e == e

while we can write ifM

ifM :: Monad m => m Bool -> m a -> m a -> m a
ifM mbool th el = do
  bool <- mbool
  if bool then th else el

such that

ifM (return True)  t e == t
ifM (return False) t e == e

This impossibility arises because ifA embodies exactly the idea of the result computation depending upon the values embedded in the argument computations.

More Related Contents:

  1. Good examples of Not a Functor/Functor/Applicative/Monad?
  2. Applicatives compose, monads don’t
  3. How to interpret bind/>>= of the function instance?
  4. Why should Applicative be a superclass of Monad?
  5. How to handle side effect with Applicative?
  6. What is a monad?
  7. Monads with Join() instead of Bind()
  8. Operating on a return from a Maybe that contains “Just”
  9. A monad is just a monoid in the category of endofunctors, what’s the problem?
  10. Is monad bind (>>=) operator closer to function composition (chaining) or function application?
  11. How to extract value from monadic action
  12. Large-scale design in Haskell? [closed]
  13. Distinction between typeclasses MonadPlus, Alternative, and Monoid?
  14. What is the purpose of the reader monad?
  15. Is Haskell truly pure (is any language that deals with input and output outside the system)?
  16. Euler 43 – is there a monad to help write this list comprehension?
  17. Haskell: I/O and Returning From a Function
  18. Why does haskell’s bind function take a function from non-monadic to monadic
  19. Defining a new monad in haskell raises no instance for Applicative
  20. What is a monad?
  21. Is there a way to place some impure code inside pure functions?
  22. What are free monads?
  23. Why are side-effects modeled as monads in Haskell?
  24. Is there a monad that doesn’t have a corresponding monad transformer (except IO)?
  25. Monoidal Functor is Applicative but where is the Monoid typeclass in the definition of Applicative?
  26. How to return a pure value from a impure method
  27. How does the ST monad work?
  28. functions as applicative functors (Haskell / LYAH)
  29. How Monads are considered pure?
  30. Is Haskell’s mapM not lazy?

Leave a Comment