Monads in Small Bites  Part II  Applicative Functors
This is Part II of my Monads tutorial. Make sure you read the previous parts:
Part II  Applicative Functors (this post)
Applicative Functors
In Part I I talked a little about Haskell type signatures and introduced Functors, which provide a way to map standard functions over values which are wrapped inside a Functor  we used fmap
for that. You might want to skim through it again as a refresher.
Now suppose you have Functors that wrap functions and that you want to apply those wrapped functions to other Functors, maybe even composing new functions on the way!
What then?
Well you’re in luck! Applicative Functors do just that! They’re Functors on steroids.
Here’s how Haskell defines the Applicative data type:
1 2 3 

Based on our previous knowledge of Haskell’s type signatures, we can infer from this definition that in order for it to be an Applicative Functor, f
must already be a Functor.
Let’s break this down and have a closer look at the two new functions this type introduces:
pure is a function that takes a value
a
and wraps it into a minimal Functorf
.<*> is a function that takes two arguments: the first is a Functor
f
that wraps a function of typea > b
. The second argument is a Functorf
that wraps a value  which could be a function!  of typea
. The final result is a Functorf
that wraps some value of typeb
 which was obtained by somehow applying the function(a > b)
to the Functorf a
.
pure
has a straightforward explanation whereas <*>
is a bit more involved.
To clear things up, I’ll show the type signatures again but this time as if they only worked with the List Functor that we’ve been working on:
1 2 

Let’s revisit those definitions:
pure is a function that takes a value
a
and puts it into an empty list, returning the resulting single element list.<*> is a function that takes two arguments: the first is a list containing one or more functions of type
a > b
. The second argument is a list of one or more values  or functions!  of typea
. The final result is a list of one or more values of typeb
 which was obtained by somehow applying the function(a > b)
to the Functorf a
.
Enough definitions though! Let’s extend our List Functor and make it an Applicative as well.
While we’ll still be using the List Functor we implemented in Part I, this time I’ll implement its Applicative version using multimethods for a change. Here’s the code:
1 2 3 4 5 6 7 8 9 10 11 12 13 

By focusing on the List as an Applicative Functor we can more easily understand what these functions do. From the code above, pure
’s job is a simple one: all it does is wrap it’s argument v
into a minimal List functor which in our case means a Functor wrapping a one element list.
<*>
on the other hand is responsible for somehow unwrapping the functions brought in by the Applicatives in fs
and applying them to the [Applicative] Functors in xs
. It does that by using list comprehensions and wraps the result into a new List Functor.
Study this code carefully. It can be tricky.
Note: When I first encountered <*> I had no idea what this function was called. I asked the twittersphere and it seems it’s called
apply
. In the process of figuring this out I was enlightened by this conversation. It turns out<*>
has several names. Can you guess which one is my favorite? :)
With the Applicative functions defined for our List, let’s take it for a spin:
1 2 3 4 5 6 7 8 

There should have been no surprises here. Read the code again and make sure it’s all fresh before moving along.
Don’t break the law
Just as Functors, Applicative Functors also need to obey some laws:
Identity
Feeding a function
f
topure
and applying the resulting Applicative to the Functorv
should be the same as directly mappingf
over the Functorv
In Haskell speak:
1


And this is the proof, in Clojure:
1 2 3 4 5 6 7 8 9 

Composition
The result of applying an Applicative Functor that yields the function composition operator to the Applicative
u
, then apply the resulting Functor tov
and finally applying that result to the final Applicativew
should be the same as applyingv
tow
and then applyingu
to the resulting Applicative.
That was a mouthful! Let’s see how Haskell tells this story:
In Haskell:
1


I needed to cheat a bit in Clojure to prove this law since functions are not curried by default like they are in Haskell. But this code should still clearly show how this law holds:
1 2 3 4 5 6 7 8 9 10 11 12 

Homomorphism
The result of applying the
pure
value off
to thepure
value ofx
should be the same as applyingf
directly tox
and then feeding that intopure
.
In Haskell:
1


And in Clojure:
1 2 3 4 5 6 7 8 9 

Interchange
The result of applying an Applicative Functor
u
to thepure
value ofy
should be the same as taking the Applicative obtained by callingpure
with a function that applies its argument toy
and then applying that tou
In Haskell:
1


This type signature presents new syntax so before proving the law in Clojure, I want to explain what ($ y)
means.
In Haskell, $
is the function application operator. So if we give y
a value of 10, I can show you that in this law $
essentially translates to a single argument function that applies its argument to 10:
1 2 3 4 5 6 7 8 

Now, to the proof in Clojure:
1 2 3 4 5 6 7 8 9 

This brings us to the end or Part II. Two down and two to go.
I hope you’re still with me but go home now.
Or better yet go to the gym lift some weights and think about these Functors on steroids. When you’re back, look out for Part III.