In your homework you were implementing the Supply monad, and while you did implement the necessary functionality, I provided you with the necessary boilerplate code, which was:

instance Functor (Supply s) where
    fmap = mapSupply

instance Applicative (Supply s) where
    pure = pureSupply
    (<*>) = mapSupply2 id

instance Monad (Supply s) where
    return = pureSupply
    (>>=) = bindSupply

We have already discussed the Monad type class; today I will introduce the other two.

Functor

Remember that type classes are used when you find that a common functionality is repeated at different types. The functionality captured by the Functor type class is that of “applying a pure function under a type constructor”.

Type constructors

I believe this is the first time I mention the word type constructor, so let me digress for a moment. Consider this list of types:

Bool
Integer
Maybe
Stream
Supply

It is obvious what a Bool or what an Integer is: it describes some value at runtime, such as True or 42. The same cannot be said about Maybe, or Stream. There are no values of type Maybe, that simply does not make sense. The type Maybe is not a proper type of its own, but rather it is a type constructor, in that if you apply Maybe to another type – such as Bool, then you get a proper type Maybe Bool that has values, such as Just True and Nothing, that you can inspect and pass around and so on.

The type constructor Supply is even worse: Supply is not a proper type, but Supply Bool is still not a proper type. You need to apply Supply to two proper types to get something that has values. So Supply is a type constructor, but of a different kind than Maybe.

Kinds

Does Maybe Stream make sense? It does not: Maybe takes a proper type (like Bool) and turns it into a new proper type Maybe Bool. But since Stream is not a proper type itself, Maybe Stream does not make sense.

So we have basic types and type constructors, and not all combinations make sense. This is just like with functions and values! And indeed, types and type constructors have their own, separate, type system that ensures that only sensible combinations are used. To keep things separate, the type of a type is called its kind, so we have a kind system.

The basic kind is called star and written * (in future versions of Haskell, this will be called Type). Bool and Integer have kind *.

Type constructors such as Maybe and Stream have kind * -> *: They are functions (on the type level) that map types (of kind star) to types (of kind star).

And our Supply type constructor has kind * -> * -> *. From this kind signature you can read that you have to apply it to two types of kind star to get a type of kind star.

Another type constructor of that kind is the arrow itself:

Prelude> :kind (->)
(->) :: * -> * -> *

Some more complicated kind signatures, such as (* -> *) -> * exist, although we did not yet see an example for that. What can you do with such a type constructor?

You can ask GHCi for the kind of a type or type constructor:

Prelude> :kind Bool
Bool :: *
Prelude> :kind Maybe
Maybe :: * -> *

You can also ask for the kind of a type class:

Prelude> :kind Eq
Eq :: * -> GHC.Prim.Constraint
Prelude> :kind Monad
Monad :: (* -> *) -> GHC.Prim.Constraint

This tells us that the Eq type class has one parameter, which has to be a type of kind star, while Monad is a type class whose instances are type constructors of kind * -> *. This makes sense, because in the type signatures of the methods of the Monad type class the parameter of the type class m is applied to a type. We can therefore not have an instance Monad Bool, we can have Monad Maybe, and we cannot have Monad Supply. But did we not have that in the homework? No! We defined a Monad instance for Supply s (for any type s). If you partially apply the type constructor Supply to one argument, you get something of kind * -> *.

All you learned about types on the term level applies here as well.

Back to Functor

If I now say that the functionality captured by the Functor type class is that of “applying a pure function under a type constructor”, that hopefully means more to you.

We have seen the pattern before twice:

mapList :: (a -> b) -> List a -> List b
mapSupply :: (a -> b) -> Supply s a -> Supply s b

and I’m sure you would not doubt the existence and usefulness of a functions

mapMaybe :: (a -> b) -> Maybe a -> Maybe b
mapTree :: (a -> b) -> Tree a -> Tree b -- the tree from last homework

The common pattern that emerges here is

class Functor f where
  fmap :: (a -> b) -> f a -> f b

Like any good type class, this comes with a few laws:

fmap id  ==  id
fmap (f . g)  ==  fmap f . fmap g

Remember that f . g is the function composition of f and g.

One implication of these laws is that if f is something with an effect of some sort (like IO), then applying a function via fmap does not not change the effect.

Examples

Functor instances are usually straight-forward to implement. Here are examples:

data Tree a
    = Node [Tree a] -- a different tree!
    | Leaf a

instance Functor Tree where
    fmap f (Node ts) = Node (map (fmap f) ts)
    fmap f (Leaf x)  = Leaf (f x)

data GenTree f a -- kind (* -> *) -> * -> *
    = Node (f (GenTree f a))
    | Leaf a

instance Functor f => Functor (GenTree f) where
    fmap f (Node ts) = Node (fmap (fmap f) ts)
    fmap f (Leaf x)  = Leaf (f x)

data Proxy a = Proxy
instance Functor Proxy where
    fmap _ Proxy = Proxy

Not all type constructors can be made instances of Functor. Here are two examples:

data Powerset a = Powerset (a -> Bool)
data Enum a     = Enum (a -> Integer) (Integer -> a)

But the vast majority of data types can be nice functions, and it is really useful.

By the way: There is the operator (<$>) that can be used instead of fmap in case infix is nicer. This makes the correspondence between f x (apply f to the pure value x) and f <$> x (apply f to the result of the computation x) clearer.

Applicative

The other type class that we instantiated in the homework is Applicative, which is a generalization of Functor. There are two ways of motivating the primitive Applicative combinator:

Deriving `<*>`

Compare the types of pure function application, conveniently expressed using $, and fmap:
```
($)   ::                    (a -> b) ->   a ->   b
(<$>) :: Functor f =>       (a -> b) -> f a -> f b
```
We see that the argument is now hidden behind a type constructor. We reach the primitive combinator of Applicative if we do the same to the function:
```
(<*>) :: Applicative f => f (a -> b) -> f a -> f b
```
This is a real generalization, as you cannot implement that function with just a Functor instance.

If you think of f describing some kind of effect (IO, failure, nondeterminism etc.), then this means that not only the argument in the (generalized) function application is obtained in an effectful way, but also the function.
Looking again at the type of fmap, we see that it applies an unary function to a now effectfully captured argument:
```
fmap ::   Functor f =>     (a -> r)      -> f a        -> f r
```
We can try to generalize that to binary functions:
```
liftA2 :: Applicative f => (a -> b -> r) -> f a -> f b -> f r
```
(The function liftA2 is not part of the Prelude, but you get it if you import Control.Applicative.)

Again we find that just using what is provided by Functor, we cannot implement this combinator, so this is a real generalization.

Both views are equivalent. If we have <*> and <$> from Functor, we can get liftA2:

liftA2 f x y = f <$> x <*> y

We can also do the other direction:

f <*> x = liftA2 id f x

What if we generalize liftA2 again to ternary function? Do we get yet another concept? No, we do not! The applicative interface is enough to implement

liftA3 :: Applicative f => (a -> b -> c -> r) -> f a -> f b -> f c -> f r
liftA3 f x y z =  f <$> x <*> y <*> z

and in fact, liftA2 etc. are rarely used and chains of <$> and <*> are used instead in idomatic code using some applicative-based interface.

Return of the purity

In order to instantiate the Applicative type class, besides giving a definition for <*>, we have to give a definition for

pure :: Applicative f => a -> f a

which injects a pure value into whatever f represents. This is exactly the same as the return that we discussed two weeks ago, so I will not dwell on it.

Laws

The Applicative type class has laws:

pure id <*> v = v                            -- identity
pure (.) <*> u <*> v <*> w = u <*> (v <*> w) -- composition
pure f <*> pure x = pure (f x)               -- homomorphism
u <*> pure y = pure ($ y) <*> u              -- interchange

The main intuition here is that that <*> is associative (due to the composition law) and that pure really is pure, and thus can be pushed around.

Example instances

Some types have only one sensible instance for Applicative. For example

instance Applicative Maybe where
    pure = Just
    Just f <*> Just x = Just (f x)
    _ <*> _ = Nothing

For lists there are two possible instances that come to mind. The first one corresponds to the notion of nondeterministic evaluation that we already know form its Monad instance, where we apply every function on the left to every argument on the right:

instance Applicative [] where
    pure x = [x]
    []     <*> xs = []
    (f:fs) <*> xs = map f xs ++ fs <*> x

The other one involved zipping lists. Note the peculiar choice of pure: it has to be that one for the identity law to hold:

instance Applicative [] where
    pure x = repeat x
    (<*>) = zipWith ($)

The Haskell standard library provides the former instance. If you want the latter, you have to use the ZipList wrapper provided in Control.Applicative.

Monad ⊂ Applicative ⊂ Functor

Applicative lies inbetween Functor and Monad in the sense that when you have a Monad instance, you also have an Applicative instance, and when you have an Applicative instance, you have a Functor instance.

To see this, we have to define two Applicative methods using the Monad combinators, either directly, or using do-notation (which might be more educating). pure is boring, as that is just return. Here is <*>:

f <*> x = f >>= (\f' -> x >>= (\x' -> return (f' x')))
-- or
f <*> x = do
    f' <- f
    x' <- x
    return (f' x')

And now we can define fmap in terms of the Applicative combinators:

fmap f x = pure f <*> x

Using these definitions we could prove the Applicative laws from the Monad laws, and similarly the Functor laws from the Applicative laws, but we do not do that now.

It is also expected, i.e. part of the laws, that these equalities hold for any type constructor that has instances of Functor, Applicative and Monad, although they are free to have possibly more efficient implementations.

So every Monad is an Applicative. Are there Applicative instances that do not have a corresponding Monad instance? Yes there are.

Here is one example:

data ConstString a = ConstString String -- special case of data Const a b = Const a
instance Applicative ConstString where
    pure x = ConstString ""
    ConstString s1 <*> ConstString s2 = ConstString (s1 ++ s2)

The monad laws require that

return x >>= f = f x

holds, in particular for x = "Hello" and f = ConstString. But since return = pure and pure throws away its argument, it is easy to see that no definition of (>>=) can do that.

Another example is ZipList. Unfortunately, there is no simple argument why that is the case, but if you want you can find many posts online of people saying they found Monad instances, only to be told in what way their Monad instance does not work.

Why all this?

So what is the point of having Applicative if Monad is stronger, and you can do more with it? Because these are interfaces, e.g. between a library implementation and the library-using code, one side’s power is the other side’s constraint.

If you look at the type signature of monadic bind it is clear that sequencing is forced there: Until the first computation has not yielded a result, the second cannot start. This is different for <*> or liftM2: If the effect would be “read something from the network”, then it is now clear that the implementation could choose to parallelize these requests and start with the second even before the first one ended. The power to do this optimization relies on the restraint that you put on the user of the interface. Facebook is using that with good results in their HaXL library.

We will look in depth at an example for that power next week, and the homework sets the stage for that.