Written by Bartosz Milewski | 6/20/12 11:33 PM

The Gang of Four book introduced many a C++ programmer to the world of patterns. Those patterns are mostly based on everyday examples, although there are a few more abstract ones like Strategy. In Haskell (and other functional languages) most patterns are very abstract. They are often based on mathematical constructs; category theory being a major source of ideas.

Arguably it's easier to grok terms like Factory, Facade, or Visitor from the GoF book than the ones from the Haskell arsenal, like Monad, Monoid, or Applicative Functor.

You might not know that, but some of the best C++ programmers use functional abstractions in their work. Alexander Stepanov used many functional patterns in designing the C++ Standard Template Library -- his education in mathematics was no doubt a big factor in this groundbreaking work. I'll show you some of these patterns later.

In my previous blog I described a functional approach to asynchronicity in C++ based on the Haskell's Continuation Monad. For many readers that might have been too big of a jump -- not only is the Monad pattern unfamiliar in the imperative world, but the Continuation Monad is one of the hardest to wrap your brain around. This is why I decided to back off a little and write a few posts that will introduce functional patterns more gradually. As a bonus, these patterns will expose some interesting aspect of asynchronous programming.

Here's the plan: In this installment I will introduce the Functor pattern (the real "functor," not the misnomer for a function object). More posts on Functors, Applicative Functors, Monads, and Monoids will follow. I promise to stay away from category theory.

Let's start looking for some hidden patterns. The first one is called a type constructor. In every programming language you have some basic types like integers, doubles, etc.; and then you have ways of defining new types. Type constructors create new types from old types.

There are some built-in type constructors in C++. For instance, by adding an asterisk to any type, you create a pointer to that type (well, never say *always* in C++: there are always exceptions to every rule). You can have a pointer to `int`

, as in `int *`

), a pointer to `bool`

, a pointer to a pointer, a pointer to a function, etc. Give me any type (except for a few outliers) and I'll create a pointer to that type. Pointer is a *type constructor*.

You can create even more type constructors using templates. Generalizing a built-in pointer type constructor, we have the smart pointer type constructors, such as `unique`

*ptr<T>** or shared*

`ptr<T>`

. Again, these type constructors work for any type `T`

(with the above caveat).Arrays are another example of a built-in type constructor. You can define array types by adding square brackets to almost any type, as in `int[]`

.

Generalizing arrays, we have user-defined containers. All containers in STL are type constructors. For instance, take almost any type `T`

and you can create a `std::vector<T>`

.

Function types are also created using a built in type constructor. Take any type and append a pair of parentheses to it and you get a function type (a function returning that type, as in `int()`

).

Again, we can generalize function types to function objects, in particular the STL `std::function`

template, which is, you guessed it, also a type constructor.

In general type constructors can take more than one type as input, or no type at all (nullary type constructors). They are just like functions that operate on types rather than values.

In what follows I will concentrate on unary type constructors, because they are the building blocks of functors. An n-ary type constructor can always be turned into a unary one by providing concrete types for n-1 of its inputs. For instance, `pair<A,B>`

can give rise to unary type constructors `pair<A,int>`

or `pair<double *,B>`

.

There is another way of looking at type constructors: An object of the constructed type hides a value (or values) of the original type. That's easy to see with pointer types: a pointer to `int`

hides an `int`

. You can access that `int`

by dereferencing the pointer. The same goes for smart pointers. A container hides multiple values of its basic type. A `vector<float>`

contains floating point values. They can be accessed through indexing or through iterators.

Functions are an interesting type. They are not containers but they, too, can "hide" a value -- the value they return. This value can be accessed by executing the function. When you call a function of the type `int()`

, it returns a value of the type `int`

, etc. We'll talk more about function types later.

Now that you can recognize the Type Constructor pattern, let's look for some more structure. As I said, type constructors may be thought of as encapsulating values of their input types. You can work on those values by first exposing them, applying some transformation, and then hiding them back. But this is tedious and it breaks encapsulation. What if you had a way of transforming hidden values without exposing them to the public. That's exactly what a functor does. It's a combination of a unary type constructor and a prescription for applying functions to hidden values.

Let's try it with some of the type constructors we've seen so far. For simplicity, I'll pick one particular transformation: It takes a `string`

and returns an `int`

. Let's represent it by a function `length`

. We want to apply this transformation, which turns `string`

s to `int`

s, to various encapsulations of `string`

s, and obtain the corresponding encapsulations of `int`

s.

Let's try first doing that for a `unique`

*ptr**. We are given a unique*

`ptr<string>`

and we want to get a `unique`*ptr<int>*

`unique`

`ptr`

s is often called the Let's try it:

unique_ptr<int> liftedLength(unique_ptr<string> s) { return unique_ptr<int>(new int(length(*s))); }

We did have to expose the value hidden in the `unique_ptr`

in the implementation of the lifting, but the client can use `liftedLength`

and similar functions without breaking the encapsulation. (By the way, I'm not worrying about null pointers here -- that's a different pattern altogether.)

Now replace `length`

with any other function `f`

from `A`

to `B`

. It's very easy to generalize our lifting formula. The lifting function is traditionally called `fmap`

:

template<class A, class B> unique_ptr<B> fmap(function<B(A)> f, unique_ptr<A> a) { return unique_ptr<B>(new B(f(*a))); }

Equipped with `fmap`

we can, for instance, trim a string inside `unique_ptr`

:

fmap<string, string>(&trim, unique_ptr<string>(new string(" Hi! ")));

We can also compose lifted functions:

unique_ptr<string> p(new string(" Hi! "));auto np = fmap<string, int>(&length, fmap<string, string>(&trim, move(p)));

The notation is awkward, but the idea is simple.

The type constructor `unique_ptr<T>`

and the above lifting function, `fmap`

, form a Functor.

Now let's do the same thing with a vector of strings. The lifting of `length`

should take such a vector and return a vector of `int`

s. Piece of cake:

vector<int> liftedLength(vector<string> strings) { unsigned size = strings.size(); vector<int> lengths(size); for (unsigned i = 0; i < size; ++i) lengths[i] = length(strings[i]); return lengths; }I used indexing to access both vectors because that's what I said about accessing values hidden inside vectors. Alex Stepanov would probably shudder seeing this code. That's because he provided a very general way of lifting any function to containers. First of all, he abstracted access to all containers using iterators, and then created the

`std::transform`

algorithm which lifts any function to the level of iterators. So here's the lifting of `length`

the STL way:vector<int> liftedLength(vector<string> strings) { vector<int> lengths; transform(strings.begin(), strings.end(), back_inserter(lengths), &length); return lengths; }

Obviously, this code can be generalized to lift any function `f`

taking `A`

and returning `B`

:

template<class A, class B> vector<B> fmap(function<B(A)> f, vector<A> as) { vector<B> bs; transform(as.begin(), as.end(), back_inserter(bs), f); return bs; }

The `vector<T>`

type constructor with its corresponding `fmap`

form a Functor.

So far these have been pretty straightforward examples. Even though they were simple, expressing them in C++ produced quite a bit of syntactic noise. This noise will get increasingly louder with more complex examples. So we need a better way of expressing functional pattern in order to make progress. As I argued previously, knowing Haskell is a great help in designing and understanding more advanced patterns in C++. So let's take a little break and see what the last example would look like in Haskell.

The canonical equivalent of a C++ vector is a Haskell list. Just like `vector`

in C++, list is a type constructor in Haskell. A list of values of type `a`

(type variables are lower-case in Haskell) has type `[a]`

. The version of `fmap`

for lists is defined in the standard Haskell library called Prelude, and is called `map`

.

Here's the signature of `map`

:

map :: (a -> b) -> [a] -> [b]

Let me translate it: `map`

is a function of two arguments, the first being itself a function `a->b `

that takes an `a`

and returns a `b`

. The second argument, `[a]`

, is a list of `a`

. The result -- the thing after the last arrow -- is of type `[b]`

, a list of `b`

. The lifting of the function `length`

would be expressed in Haskell like this:

liftedLength :: [String] -> [Int] liftedLength str = map length strThe first line (it is optional because Haskell has a powerful type inference system) shows the type of the lifted function: from lists of strings to lists of integers. The second line defines the function

`liftedLength`

that takes a `str`

and applies `map`

to the function `length`

and the string `str`

. (In Haskell you don't use parentheses around function arguments, neither in the definition nor in the application.)Interestingly, because of currying (see the Appendix), the signature of `map`

can be rewritten as (pay attention to parentheses):

map :: (a -> b) -> ([a] -> [b])

which can be read as `map`

being a function that takes a function `a->b `

and returns a function `[a]->[b]`

. In fact the definition of `liftedLength`

can be simplified to:

liftedLength :: [String] -> [Int] liftedLength = map length

which defines one function in terms of another (curried) function. Now the whole "lifting" thing starts making sense. We start with the function `length :: String->Int `

and lift it to a function `liftedLength :: [String]->[Int]`

. The lack of currying in C++ makes such simple things difficult to express.

You can lift any function, not only `length`

, this way. Just look at the signature of `map`

, which is exactly what you'd for the general lifting function `fmap`

for lists. So `map`

is the `fmap`

for lists:

fmap = map

Let's go back to some more C++ examples.

This is a little tricky, but the ability to think of functions as first class citizens is an essential skill in programming, and practically all imperative languages learned to recognize this fact. In general, a function type constructor takes one type for the return value and zero or more types for arguments. For simplicity, let's first consider nullary functions. Given any type `T`

we can construct a function-type `T()`

or, more generally, `std::function<T()>`

: a function that takes no arguments and returns `T`

. The generalized function object, `std::function`

, not only deals with regular functions, but also with function objects (objects that overload `operator()`

), lambdas, closures, methods, etc.

How can we lift the function `length`

to operate on functions? The lifted function must accept a function returning `string`

and produce a function returning `int`

:

function<int()> liftedLength(function<string()> fStr)

In order to return a function, we have to generate it on the fly. In C++11 we can do that with lambdas. Here, `liftedLength`

should return a function that extracts the string from `fStr`

and applies `length`

to it. Remember, extracting a value for a function means simply executing it. Here it is:

function<int()> liftedLength(function<string()> fStr) { return [fStr]() { return length(fStr()); }; }

Notice that the returned function is really a closure -- it captures `fStr`

. This anonymous function/closure is converted into `std::function`

object upon return.

This formula can be easily generalized to lifting an arbitrary function:

template<class A, class B> function<B()> fmap(function<B(A)> f, function<A()> fA) { return [f, fA]() { return f(fA()); }; }

For many C++ programmers this might be the first encounter with higher order functions that take functions as arguments and also return functions. In Haskell this is standard fare.

We conclude that the nullary function constructor and the corresponding `fmap`

form a Functor. In itself, this particular functor might not seem very useful, but it is a stepping stone toward much more interesting cases, like continuations, threads, or asynchronous calls.

In Haskell, which shuns side effects, a function that takes no arguments is not very interesting. So let's generalize the above example slightly: we'll look at functions taking some fixed type, `c`

, with no restrictions on the return type `a`

. Let's call such functions "readers" because they can only read c, not modify it. You might think of values of type `c`

as, say, some configuration data that's passed around.

Here's the type constructor:

newtype Reader c a = Reader (c -> a)

I have defined a new data type, `Reader`

parameterized by two types `c`

and `a`

. The right hand side of the definition says that I can create a `Reader`

from any function `c->a `

that takes `c`

and returns `a`

. It also says, in the same breath, that in order to extract that function later, I'll have to pattern-match a `Reader`

object using the pattern `(Reader f)`

. Trust me, that's what it says.

The major reason for extracting a function from a reader is to apply it to some value of type `c`

. Let's define a separate helper function to do just that:

run :: Reader c a -> c -> a run (Reader f) cfg = f cfg

The first (optional) line shows the type signature of `run`

: It's a function that takes a reader and some config, and returns a value of type `a`

. The second line is the implementation. The first argument to `run`

is pattern matched to `(Reader f)`

. This way we gain access to the function `f`

that was encapsulated in the reader argument. The second argument is config `cfg`

. In the body of the definition we apply `f`

to `cfg`

.

The lifting of `length`

is now pretty straightforward:

liftedLength :: Reader c String -> Reader c Int liftedLength rdrStr = Reader (λ cfg -> length (run rdrStr cfg))

We have to return a new function (encapsulated in the `Reader`

constructor): the lambda that takes an argument `cfg`

and returns the result of `length`

acting on the result of `fStr`

applied to `cfg`

. You might want to read this description a few times before it clicks.

The generalization to `fmap`

is straightforward -- just replace `length`

with `f`

:

fmap :: (a -> b) -> Reader c a -> Reader c b fmap f rdA = Reader (λ cfg -> f (run rdA cfg))

What does a `Reader`

look like in C++? The type constructor is a function-type constructor that is parameterized by two types, `A`

and `C`

:

function<A(C)>

We'll keep `C`

fixed and vary only `A`

(we are in fact currying the type constructor when we provide concrete type for `C`

). Here's the definition of `fmap`

(notice: the same `C`

throughout):

template<class C, class A, class B> function<B(C)> fmap(function<B(A)> f, function<A(C)> rdA) { return [f, rdA](C cfg) { return f(rdA(cfg)); }; }

After seeing the Haskell code, that was pretty easy, right? Unfortunately things are never easy in C++ so in the next blog post I'll show you a more careful implementation of `Reader`

, as well as `Async`

from my previous blog. For now, let us conclude that `Reader`

together with the corresponding `fmap`

is a Functor. We have a type constructor and a prescription for applying functions to its "hidden" value.

Again, the `Reader`

functor doesn't seem like it would be very useful in C++. Why would anyone carry around some configuration data if it's easier to make them global? Hmm... What about many different configurations? Access them by key? What about passing the key then? And what if you change the word "configuration" to "credentials"? Would you still want to make them global?

In C++ we'll just work with the functor pattern without abstracting it further. But in Haskell such patterns can be generalized using type classes. The closest thing to type classes in C++ were concepts, which didn't make it into the C++11 Standard. A Haskell type class describes a whole family of types that have something in common. In the case of functors, this common thing is the presence of the lifter: the function `fmap`

. But a Functor doesn't just describe a type, it describes a type constructor -- a particular mapping from types to types. So a `Functor`

type class unifies a whole class of type constructors. Here's the definition of a `Functor`

in its full glory:

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

You can read it as: A type constructor `f`

is a `Functor`

if there is a function `fmap`

with the type signature:

fmap :: (a -> b) -> f a -> f b

Notice that `f`

is applied to types `a`

and `b`

. That's how we know that `f`

is a type constructor. In fact this is how the Haskell compiler knows that `f`

is a type constructor. It looks at the usage.

Having defined a type class we can now tell Haskell which type constructors are `Functor`

s. We do that by declaring instances of the type class. For example, I told you that a list constructor `[]`

is a functor. Here's how I tell that to Haskell:

instance Functor [] where fmap = mapThe instance definition must provide the implementation of the associated function (or functions, plural, in general). Here we define

`fmap`

in terms of an existing function, `map`

.Would any implementation of `fmap`

work for a `Functor`

? Not really. There are two additional functor laws which unfortunately cannot be enforced by Haskell.

The first law states that the lifting of the identity function (called `id`

in Haskell) must also be identity:

fmap id = idIn other words if you apply identity to the values hidden in your type constructor, nothing will change.

The second law states that lifting a composition of two functions is the same as composing the lifted functions.

fmap (f . g) = fmap f . fmap gThe dot means the application of one function to the result of another.

It's good to know about these laws, but in most practical cases they are trivially true. And, when a type constructor is a good functor candidate, there usually is only one obvious way to implement `fmap`

, as I demonstrated in the examples above.

The Functor pattern is ultimately about code reusability and composability -- two major pillars of programming. Whenever you create a new way of encapsulating data of arbitrary type, that is a type constructor, you should ask yourself the question:

How can I reuse my existing libraries on data that is encapsulated through this type constructor?

I'm talking about libraries that contain functions like `length`

, which don't know how to work on a `unique_ptr<string>`

or a `vector<string>`

.

The naive approach would be to expose the encapsulated data in an ad hoc manner and apply library functions to it. For a multitude of reasons, this is not a good solution, and it gets really hairy when you're dealing with function-type constructors. The Functor pattern allows you to accomplish all this without breaking the encapsulation, simply by defining one template function, `fmap`

.

The Functor pattern is especially powerful when working with function types. A function does not contain a value (unless it's a constant function) -- it is a "promise" to create a value when executed. A functor allows you to arbitrarily compose operations *on* (the results of) those functions without immediately executing them. This is the basis of the general approach to asynchronous APIs I described in my previous post and will elaborate on in my next post.

I'd like to thank Eric Niebler for many valuable comments on the draft of this post.

Many people find function syntax in Haskell confusing because there are no parentheses around, or commas between, arguments. It takes some getting used to to interpret the following pattern:

ex1 ex2 ex3as a call to the function produced by

`ex1`

with arguments produced by `ex2`

and `ex3`

(the `ex`

s stand for arbitrary expressions). It's even more confusing when the expressions themselves are parenthesized, as in this made up example:
(getOp "add") (getX n) (getV k m)This syntax makes perfect sense in Haskell, where currying is a national sport. In other languages, when you call a two argument function with one argument you get an error: Not enough arguments. In Haskell you get a curried function. It's a new function that takes one (remaining) argument. The only way you can do it in C++ is by using a (somewhat awkward) template function

`bind`

. For instance, this is what you'd do if you wanted to curry a two-argument function `concat`

, passing it `"Hello, "`

as the first argument:function<string(string)> greet = bind(&concat, "Hello, ", placeholders::_1); cout << greet("Haskell!") << endl;

Here's the equivalent code in Haskell (where, incidentally, concat is an infix operator `++`

):

greet = (++) "Hello, " greet "Haskell!"

Now the type signatures of two-argument functions start making sense:

f :: a -> b -> c

This means that the function `f`

takes two arguments of types `a`

and `b`

and returns `c`

; or, equivalently, that it takes one argument of type `a`

and returns a function `b->c`

. It's all the same, you see, and right associativity of the arrow `->`

makes the use of parentheses redundant (here's the equivalent parenthesized version: `f :: a -> (b -> c)`

).
[twitter-follow screen_name='BartoszMilewski']