Applicatives, Monads and Concurrency

With the Functor-Applicative-Monad proposal just around the corner, I’ve been wondering what exactly the relation between Applicative and Monad is. Every Monad can be made a Functor with fmap = liftM where

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

In fact, parametricity guarantees that fmap = liftM; it’s a free theorem. There is another law relating Functor and Monad, ma >>= f = join (fmap f ma). This law is particularly interesting because if you define a Monad the way mathematicians do using join instead of (>>=) then you must have Functor as a superclass in order to define (>>=). So it seems very natural for Functor to be a superclass of Monad.

However, it’s not so obvious to me why Applicative should be a superclass of Monad. It’s true that every Monad can be made an Applicative with (<*>) = ap where

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

One should naturally expect that (<*>) = ap is a law when Applicative is a superclass of Monad. But, (<*>), unlike fmap, is not uniquely determined. A type constructor may have more than one instance. For example, lists have two useful instances.

ap :: [a -> b] -> [a] -> [b]
ap fs as = [f a | a <- as, f <- fs]

zap :: [a -> b] -> [a] -> [b]
zap [] _ = []
zap _ [] = []
zap (f:fs) (a:as) = (f a) : zap fs as

ap delivers a list of all functions in the first list applied to all values in the second list while zap goes down the lists applying functions to values at the same index. So which do you choose? Well, ap is the one which is compatible with the Monad instance on lists, so it wins. zap is used as the Applicative instance for a newtype on lists, the ZipList. Interestingly, there is no compatible Monad instance on ZipLists.

The ambiguity for lists resolves nicely enough. But in creating data types for concurrency, one runs into cases where you might want Applicative and Monad instances where (<*>) /= ap. A really good example can be found in the Haxl paper. Haxl is a library developed by Facebook to manage data requests in a way to maximize concurrency for the sake of efficiency. In section 4 of the paper, we find out that for the type constructor Fetch,

Blocked (Done (+1)) <*> Blocked (Done 1) = Blocked (Done 2)
Blocked (Done (+1)) `ap` Blocked (Done 1) = Blocked (Blocked (Done 2))

I won’t go over the details here but the takeaway is that the Applicative can take advantage of looking at both arguments of (<*>) which are both in Fetch while the Monad cannot because it must use (>>=) the second argument of which is a function with pure input. So here we have an example of a law breaking Applicative/Monad. As with ZipList, there is no Monad instance which is compatible with the Applicative instance. So why not newtype? The motivation is that we want to be able to use concurrencly implicitly without the overhead of having to wrap and unwrap a newtype. Whether that justifies breaking the law is a judgment call. Notice however that the law breaks in a well defined way, that is (<*>) is equal to ap up to idempotency of Block, the relation that Block . Block = Block .

I want to work through another example that was inspired by concurrency in Purescript.

First lets take care of the imports.

import Control.Applicative
import Control.Concurrent
import Control.Concurrent.Async
import Control.Concurrent.MVar
import Control.Monad.IO.Class
import Data.Traversable
import Prelude hiding (mapM)
import System.Random

Annoyingly we have to hide either the mapM from Prelude or Data.Traversable but this should be fixed by the Foldable/Traversable in Prelude proposal. The type constructor we’ll work with is for callbacks.

newtype Callback a = Callback {runCallback :: (a -> IO ()) -> IO ()}

You should recognize that Callback is isomorphic to ContT () IO, so we can just crib the definitions of Functor and Monad instances from your favorite source. We’ll also give a MonadIO instance.

instance Functor Callback where
    fmap f c = Callback (\k -> runCallback c (k . f))

instance Monad Callback where
    return a = Callback (\k -> k a)
    c >>= f = Callback (\k -> runCallback c (\a -> runCallback (f a) k))

instance MonadIO Callback where
    liftIO io = Callback (\k -> io >>= k)

For the Applicative instance we want to take advantage of the ability to do our IO side effects concurrently. Let’s see how this works.

instance Applicative Callback where
    pure a = Callback (\k -> k a)
    cf <*> ca = Callback $ \k -> do
        vf <- newEmptyMVar
        va <- newEmptyMVar
        let finish = do f <- takeMVar vf
                        a <- takeMVar va
                        k (f a)
        race_ (runCallback cf (putMVar vf) >> finish)
              (runCallback ca (putMVar va) >> finish)

Ok, so what’s going on the definition of (<*>)? Well first we create new empty mutable variables in which we will store a function f and a value a to apply it to, but which we must perform some IO effects to get. finish is where we perform the callback on the result. finish looks a whole lot like ap. The magic happens in the function race_ which is from Simon Marlow’s delightful async package. It runs two IO actions concurrently, canceling the loser. Because finish blocks when either vf or va are empty, both callbacks are run concurrently with a putMVar as the callback, filling up the variables. Then finish will unblock and the first branch to complete it wins the race.

Let’s see the difference in performance between the Applicative and Monad instances on an example.

square :: Int -> Callback Int
square n = do liftIO $ do let second = 10^6
                          random <- randomRIO (0 , second)
                          threadDelay random
                          let time = fromIntegral random / fromIntegral second
                          putStrLn $ "Squaring "
                              ++ show n ++ " after "
                              ++ show time ++ " seconds."
              return (n^2)

main = do putStrLn "Traversing [1..10] using Monad"
          runCallback (mapM square [1..10]) print
          putStrLn "Traversing [1..10] using Applicative"
          runCallback (traverse square [1..10]) print

And here’s an example of what the output looks like.

Traversing [1..10] using Monad
Squaring 1 after 0.723773 seconds.
Squaring 2 after 0.603614 seconds.
Squaring 3 after 0.203097 seconds.
Squaring 4 after 0.535666 seconds.
Squaring 5 after 0.414605 seconds.
Squaring 6 after 0.807218 seconds.
Squaring 7 after 0.580662 seconds.
Squaring 8 after 0.715894 seconds.
Squaring 9 after 0.641902 seconds.
Squaring 10 after 0.180422 seconds.
Traversing [1..10] using Applicative
Squaring 4 after 4.8804e-2 seconds.
Squaring 5 after 0.140811 seconds.
Squaring 3 after 0.142185 seconds.
Squaring 7 after 0.373733 seconds.
Squaring 9 after 0.386626 seconds.
Squaring 8 after 0.393645 seconds.
Squaring 1 after 0.417399 seconds.
Squaring 6 after 0.780407 seconds.
Squaring 2 after 0.803894 seconds.
Squaring 10 after 0.96637 seconds.

The Monad is forced to perform the effects consecutively, taking up to 10 seconds (ignoring the time it takes to get a random number and to print). The Applicative performs the effects concurrently, taking only up to 1 second. So here’s another example where (<*>) /= ap and we may be somewhat justified by the desire for implicit concurrency. Notice that it’s just the effects that are different, not the result. Said another way, if we bind x <- mf <*> ma and y <- mf `ap` ma then we have that x = y so we’re breaking the law but not flagrantly.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: