Category: Functions

Continuation Passing Style

Let’s take a break from type classes and take a brief look at one of the more esoteric concepts of functional programming. Continuation passing style (CPS) is a method of programming which allows for intricate manipulation of control flow while still maintaining functional purity.

Continuations can be used to implement a whole range of things from exceptions to coroutines, but today we’ll just introduce them and a few interesting and useful concepts.

Suppose we have a show function which just prints things to the screen.

auto show = [](const auto& v){std::cout << v << "\n";};

Typically we deal with calling functions, storing and modifying return values, then passing those values on to the next functions:

auto make_one = [](){return 1;};

// prints 1
show(make_one());

In CPS, functions have an extra argument which is what handles the result. This is the continuation, named “k” by convention.

auto one_cps = [](auto&& k){return k(1);};

// Also prints 1
one_cps(show);

The one_cps takes a function as an argument and calls it with what would normally have been the return value. Note that it is written as a generic lambda, this is because we want to pass any type of function while avoiding “unresolved overloaded function” errors.

Other functions can be converted into CPS in a rather straightforward way:

auto add_cps = []<class T>(const T& lhs, const T& rhs, auto&& k)
{
    return k(lhs+rhs);
};

auto sub_cps = []<class T>(const T& lhs, const T& rhs, auto&& k)
{
    return k(lhs-rhs);
};

auto mul_cps = []<class T>(const T& lhs, const T& rhs, auto&& k)
{
    return k(lhs*rhs);
};

auto div_cps = []<class T>(const T& lhs, const T& rhs, auto&& k)
{
    return k(lhs/rhs);
};

auto eq_cps = []<class T>(const T& lhs, const T& rhs, auto&& k)
{
    return k(lhs==rhs);
};

// etc...

add_cps(1,2,show); // prints 3
times_cps(3,4,show); // prints 12

More intricate functions can be written combining other CPS functions, for example this function which returns the sum of the squares of two numbers:

auto sum_of_squares_cps = [&]<class T>(const T& lhs, const T& rhs, auto&& k)
{
    return mul_cps(lhs,lhs,[&](const T& lhs2){
            return mul_cps(rhs,rhs,[&](const T& rhs2){
                return add_cps(lhs2,rhs2,k);
            });
        });
};

That’s quite a mess, let’s break it down by unwrapping it layer by layer. The outermost layer is a call to mult_cps which is used to square the left number:

return mul_cps(lhs,lhs,
        // ...
    );

The next layer is the continuation of the first layer:

[&](const T& lhs2){
    return mul_cps(rhs,rhs,
        // ....
    }

As with the outer layer, we are using mul_cps to square the right number.

Additionally, as the continuation of the first layer, we receive the argument lhs2. Now this is a clever trick, by passing it as the argument, we can access the result of the first computation by name despite never actually storing in a variable.

Note: We will be using this trick quite often in the future!

The last layer uses the trick as well:

[&](const T& rhs2){
        return add_cps(lhs2,rhs2,k);
    }

We capture lhs2 and finally compute the sum of the squares using add_cps. As this is the final result of the computation, the continuation is that of the entire sum_of_squares_cps function.

The function can then be used as expected:

sum_or_squares_cps(3,4,show); // prints 25

You can even write recursive functions using CPS! This rather hard to do generically, since resolving the templates will involve an infinite loop, but it’s possible to get something together:

std::function<void(int,const std::function<void(int)>&)> factorial_cps =
    [&](int n, const std::function<void(int)>& k){
        eq_cps(n,0,[&](bool done){
                if (done)
                    k(1);
                else
                    sub_cps(n,1,[&](int m){
                            factorial_cps(m,[&](int p){
                                    mul_cps(n,p,k);
                                });
                        });
            });
    };

Overall, continuation passing style is a pretty radical departure from the conventional way of programming and the next few posts will explore what can be done with these functions.

P.S. This stuff is pretty heavy on the lambda functions. Here is a good introduction to what you can do with lambda calculus.

Edit (2015-01-15): Changed function suffixes to _cps.

Tuple Forwarding

C++11 provides the very useful std::forward_as_tuple function. Unfortunately, there isn’t any standard way to unpack the tuple to the parameters of a function.

To do this, template recursion and forwarding can be used. Recursing over a tuple allows for the extraction of the arguments, at the end eval can evaluate the result:

template<size_t index>
struct tuple_eval_helper
{
    template<class Func,class TArgs,class... Args>
    static auto evaluate(Func&& f, TArgs&& t_args, Args&&... args)
        -> decltype(tuple_eval_helper<index-1>::evaluate(
            std::forward<Func>(f),
            std::forward<TArgs>(t_args),
            std::get<index>(std::forward<TArgs>(t_args)),
            std::forward<Args>(args)...
            ))
    {
        return tuple_eval_helper<index-1>::evaluate(
            std::forward<Func>(f),
            std::forward<TArgs>(t_args),
            std::get<index>(std::forward<TArgs>(t_args)),
            std::forward<Args>(args)...
            );
    }
};

template<>
struct tuple_eval_helper<0>
{
    template<class Func,class TArgs,class... Args>
    static auto evaluate(Func&& f, TArgs&& t_args, Args&&... args)
        -> decltype(eval(
            std::forward<Func>(f),
            std::get<0>(std::forward<TArgs>(t_args)),
            std::forward<Args>(args)...
            ))
    {
        return eval(
            std::forward<Func>(f),
            std::get<0>(std::forward<TArgs>(t_args)),
            std::forward<Args>(args)...
            );
    }
};

template<class Func,class TArgs>
auto tuple_eval(Func&& f, TArgs&& t_args)
    -> decltype(tuple_eval_helper<std::tuple_size<
            typename std::remove_reference<TArgs>::type>::value-1>::evaluate(
        std::forward<Func>(f),
        std::forward<TArgs>(t_args)
        ))
{
    return tuple_eval_helper<std::tuple_size<
            typename std::remove_reference<TArgs>::type>::value-1>::evaluate(
        std::forward<Func>(f),
        std::forward<TArgs>(t_args)
        );
}

Which you can use like this:

tuple_eval(std::plus<int>(),std::forward_as_tuple(1,2));

Now, suppose you have a tuple of functions that you want to call with the parameters? In similar fashion, recursively extract the functions, evaluate them and forward the result to the end where they are repackaged into another tuple:

template<size_t index>
struct multi_tuple_eval_helper
{
    template<class TFuncs,class TArgs,class... Results>
    static auto evaluate(TFuncs&& t_funcs, TArgs&& t_args, Results&&... results)
        -> decltype(multi_tuple_eval_helper<index-1>::evaluate(
            std::forward<TFuncs>(t_funcs),
            std::forward<TArgs>(t_args),
            tuple_eval(std::get<index>(t_funcs),t_args),
            std::forward<Results>(results)...
            ))
    {
        return multi_tuple_eval_helper<index-1>::evaluate(
            std::forward<TFuncs>(t_funcs),
            std::forward<TArgs>(t_args),
            tuple_eval(std::get<index>(t_funcs),t_args),
            std::forward<Results>(results)...
            );
    }
};

template<>
struct multi_tuple_eval_helper<0>
{
    template<class TFuncs,class TArgs,class... Results>
    static auto evaluate(TFuncs&& t_funcs, TArgs&& t_args, Results&&... results)
        -> decltype(std::tuple<decltype(tuple_eval(std::get<0>(t_funcs),t_args)),Results...>(
            tuple_eval(std::get<0>(t_funcs),t_args),
            std::forward<Results>(results)...
            ))
    {
        return std::tuple<decltype(tuple_eval(std::get<0>(t_funcs),t_args)),Results...>(
            tuple_eval(std::get<0>(t_funcs),t_args),
            std::forward<Results>(results)...
            );
    }
};

template<class TFuncs,class TArgs>
auto multi_tuple_eval(TFuncs&& t_funcs, TArgs&& t_args)
    -> decltype(multi_tuple_eval_helper<std::tuple_size<
            typename std::remove_reference<TFuncs>::type>::value-1>::evaluate(
        std::forward<TFuncs>(t_funcs),
        std::forward<TArgs>(t_args)
        ))
{
    return multi_tuple_eval_helper<std::tuple_size<
            typename std::remove_reference<TFuncs>::type>::value-1>::evaluate(
        std::forward<TFuncs>(t_funcs),
        std::forward<TArgs>(t_args)
        );
}

Which can be used like this:

multi_tuple_eval(
    std::forward_as_tuple(std::plus<int>(),std::multiplies<int>()),
    std::forward_as_tuple(3,4)
    );

The result is the tuple (7,12).

Esoteric and abusive to the compiler, that’s what we’re about here at Functional C++!

Note: Be careful with move semantics and invalidating stuff when using this.

Edit: Changed multi_tuple_eval to use the tuple constructor. It will now correctly return references.

Type Classes

Type classes are a feature of Haskell which is very similar to the upcoming Concepts. Both define interfaces to a data type, which can be defined separately from the data, in contrast to member functions.

To introduce the notion of type classes, let’s start with a simple one: the monoid. A monoid is an object which has a binary operation and an identity for that operation. For our purposes, we will call the identity empty() and the operation append.

The basic template for the type class follows:

template<class T>
struct monoid
{
    // T empty()
    // T append(T,T)
    static constexpr bool is_instance = false;
};

Most things are not monoids and so we also add a boolean which marks this. This allows us to do type checking using std::enable_if or static_assert.

When an object has the type class interface, we say that it is an instance of the type class. For example, the monoid instance for integers can be written as:

template<>
struct monoid<int>
{
    static int empty(){return 0;}
    static int append(int lhs, int rhs){return lhs+rhs;}
    static constexpr bool is_instance = true;
};

Now if we wanted to write a function using monoids, we could do so easily and with guarantees of type safety. For example, here is a function which “accumulates” monoid values from a vector:

template< 
    class T,
    class = typename std::enable_if<monoid<T>::is_instance>::type
    >
T accumulator(const std::vector<T>& in)
{
    T out{monoid<T>::empty()};

    for (const T& t : in)
        out = monoid<T>::append(out,t);

    return out;
}

int main()
{
    std::cout << accumulator(std::vector<int>{1,2,3}) << "\n";

    return 0;
}

Output:

6

Obviously, there are quite a few data types which display monoid behaviour, including all the fundamental data types. There’s quite a bit of repetition which can be removed, also reducing the chance for error.

Many of the monoids, including all the fundamental types implement operator+ and are value-initialized to a reasonable value. A default monoid can be written to represent this.

template<class T>
struct default_monoid
{
    static T empty(){return T{};}
    static T append(const T& lhs, const T& rhs){return lhs+rhs;}
    static constexpr bool is_instance = true;
};

// example use
template<>
struct monoid<int> : public default_monoid<int>
{};

template<>
struct monoid<char> : public default_monoid<char>
{};

We can further reduce the repetition through the use of x macros:

#define FUNDAMENTAL_TYPES\
    X(bool)\
    X(signed char)\
    X(unsigned char)\
    X(char)\
    X(wchar_t)\
    X(char16_t)\
    X(char32_t)\
    X(short)\
    X(unsigned short)\
    X(int)\
    X(unsigned)\
    X(long)\
    X(unsigned long)\
    X(long long)\
    X(unsigned long long)

#define X(a)\
    template<>\
    struct monoid<a> : public default_monoid<a>\
    {};

FUNDAMENTAL_TYPES;
#undef X

This code will generate monoid instances based on default_monoid for all the fundamental data types.

We can also use default_monoid for strings:

template<>
struct monoid<std::string> : public default_monoid<std::string>
{};

But for some types we need to customize a bit more:

template<class T>
struct monoid<std::vector<T>>
{
    static std::vector<T> empty(){return std::vector<T>{};}

    static std::vector<T> append(std::vector<T> lhs, const std::vector<T>& rhs)
    {
        for (const T& t : rhs)
            lhs.push_back(t);

        return lhs;
    }

    static constexpr bool is_instance = true;
};

I’m not going to go into every single type but, suffice it to say that containers, string streams, numerical types and many more can all instantiate the monoid type class.

The combination of generic programming and functional programming is very powerful. The accumulator function from earlier can now work with every type that is an instance of monoid! Pretty neat.

int main()
{
    int a = accumulator(std::vector<int>{1,2,3});
    std::cout << a << "\n";

    int b = accumulator(accumulator(std::vector<std::vector<int>>{{1,2,3},{4,5,6},{7,8,9}}));
    std::cout << b << "\n";

    std::string c = accumulator(std::vector<std::string>{"hello ","world","!"});
    std::cout << c << "\n";

    return 0;
}

Output:

6
45
hello world!

Function Composition

The usefulness of higher order functions is hard to dispute, you can safely and easily write functions which combine the functionality of other functions. The most basic of higher order functions is function composition, the topic of this post.

There is no standard way to compose functions, especially since there is no standard way to resolve a function’s argument and return types. Good thing that we have function traits! I will also be making use of the generalized function evaluation discussed previously.

To keep the discussion simple, I will only discuss unary functions, though conceivably one could make some clever use of std::forward_as_tuple and make a very complete and complex implementation.

Let’s start with the basics:

#include <functional>

#include "eval.h"
#include "function_traits.h"

template<class F, class G>
auto compose(F&& f, G&& g)
    -> std::function<typename function_traits<F>::return_type(
        typename function_traits<G>::template argument<0>::type)>
{
    using F_traits = typename function_traits<F>;
    using G_traits = typename function_traits<G>;

    static_assert(F_traits::arity == 1, "error: only unary functions can be composed.");
    static_assert(G_traits::arity == 1, "error: only unary functions can be composed.");

    using Arg = typename G_traits::template argument<0>::type;

    return [=](Arg arg){return eval(f,eval(g,arg));};
}

Given two functions, f(x) and g(y), compose will give us h(y) = compose(f,g) = f(g(y)). Note the use of static asserts to enforce the use of unary functions as well as to determine the argument type for the returned function.

The trailing return type uses the function_traits to cast the lambda to a valid function object. In c++14, the return type can be omitted entirely, and frankly it’s a huge improvement. Just look at that thing.

An example of this in action:

#include <iostream>

int main()
{
    auto double_then_add_three = compose(
        [](int n){return n+3;},
        [](int n){return n*2;}
    );

    for (unsigned i = 0; i < 10; ++i)
        std::cout << double_then_add_three(i) << " ";

    return 0;
}

Which outputs as expected:

3 5 7 9 11 13 15 17 19 21

Let’s try making an operator version of this. I will be choosing operator* as my composition operator.

template<class F, class G>
auto operator*(F&& f, G&& g)
{
    return compose(std::forward<F>(f),std::forward<G>(g));
}

This works quite well, until we try and combine function pointers.

#include <iostream>

int add_one(int n){return n+1;}
int times_two(int n){return n*2;}

int main()
{
    // fine
    auto double_then_add_three = [](int n){return n+3;} * [](int n){return n*2;};

    // error!
    auto double_then_add_one = &add_one * &times_two;

    return 0;
}

This is because the compiler is trying to multiply the two pointers and that makes absolutely no sense. How can we get around this? We can write our own custom operators. (I feel really bad about this! Don’t hate me!)

First we have to wrap our pointer in another object, we also add a test to see if a type is a wrapper:

template<class T>
struct wrapper
{
    wrapper(T t):value(t){};

    T value;
};

template<>
struct wrapper<void>
{};

template<class T>
struct is_wrapper
{
    enum{ value = false };
};

template<class T>
struct is_wrapper<wrapper<T>>
{
    enum{ value = true };
};

Now for the new composition operator, very similar but with some minor changes:

template<
    class F, class G,
    class = typename std::enable_if<!is_wrapper<F>::value>::type
    >
auto operator*(F&& f, G&& g)
{
    return compose(std::forward<F>(f),std::forward<G>(g));
}

template<class T>
auto operator*(T&& t, wrapper<void> v)
{
    return wrapper<T>(std::forward<T>(t));
}

template<class T, class F>
auto operator*(wrapper<T>&& t, F&& f)
{
    return compose(t.value,f);
}

#define COMPOSE * wrapper<void>() *

We can now use the macro COMPOSE as an operator which behaves exactly like compose. The macro causes the left operand to be placed in a wrapper, which then can be passed to the compose operator.

This workaround also works for objects which have their own operator* but it’s not pretty and will definitely raise some flags if you use this in production.

The end result is quite nice though, and you can see this for yourself:

#include <iostream>

int increment(int n){return n+1;}
int times_two(int n){return n*2;}

int main()
{
    auto double_then_add_three = [](int n){return n+3;} * [](int n){return n*2;};
    std::cout << double_then_add_three(20) << " ";

    auto echo = [](const std::string& s){return s+" "+s;};
    auto echo_length = &std::string::size * echo;
    std::cout << echo_length("hello") << " ";

    auto some_func = &increment COMPOSE &times_two COMPOSE &increment COMPOSE &increment;
    std::cout << some_func(-4);

    std::cout << "\n";
}

Which gives the output:

43 11 -3

Function Traits

C++11 has added the incredibly useful type_traits library. However, beyond std::is_function there isn’t really much going on for functions. Rolling your own function traits is not very difficult, and this post will show you how!

A good place to start is free functions. Using templates, it’s easy to unpack the return type, arity and argument types for a function:

template<class F>
struct function_traits;

// function pointer
template<class R, class... Args>
struct function_traits<R(*)(Args...)> : public function_traits<R(Args...)>
{};

template<class R, class... Args>
struct function_traits<R(Args...)>
{
    using return_type = R;

    static constexpr std::size_t arity = sizeof...(Args);

    template <std::size_t N>
    struct argument
    {
        static_assert(N < arity, "error: invalid parameter index.");
        using type = typename std::tuple_element<N,std::tuple<Args...>>::type;
    };
};

Which can be used like this:

float free_function(const std::string& a, int b)
{
    return (float)a.size() / b;
}

int main()
{
    using Traits = function_traits<decltype(free_function)>;

    static_assert(Traits::arity == 2,"");
    static_assert(std::is_same<Traits::return_type,float>::value,"");
    static_assert(std::is_same<Traits::argument<0>::type,const std::string&>::value,"");
    static_assert(std::is_same<Traits::argument<1>::type,int>::value,"");

    return 0;
}

The use of decltype is necessary because we need the type of the function, not the function itself. Here, decltype(free_function) resolves to the function pointer, but it is entirely possible to do something like function_traits<int(char)>.

Through template pattern matching, the compiler is capable of determining R and Args.... We can then alias return_type and get the arity from the parameter pack. Getting the arguments is slightly more complex, unpacking Args... into a tuple and accessing elements using std::tuple_element.

Functionality can be extended to function-like objects such as member function pointers and member object pointers:

// member function pointer
template<class C, class R, class... Args>
struct function_traits<R(C::*)(Args...)> : public function_traits<R(C&,Args...)>
{};

// const member function pointer
template<class C, class R, class... Args>
struct function_traits<R(C::*)(Args...) const> : public function_traits<R(C&,Args...)>
{};

// member object pointer
template<class C, class R>
struct function_traits<R(C::*)> : public function_traits<R(C&)>
{};

Const and non-const member functions are treated as separate types. This basically treats member function/object pointers as functions which take a reference to the appropriate class.

To handle functors and std::function objects (technically also a functor), we can now implement the default specialization:

// functor
template<class F>
struct function_traits
{
    private:
        using call_type = function_traits<decltype(&F::type::operator())>;
    public:
        using return_type = typename call_type::return_type;

        static constexpr std::size_t arity = call_type::arity - 1;

        template <std::size_t N>
        struct argument
        {
            static_assert(N < arity, "error: invalid parameter index.");
            using type = typename call_type::template argument<N+1>::type;
        };
};

template<class F>
struct traits<F&> : public traits<F>
{};

template<class F>
struct traits<F&&> : public traits<F>
{};

This will determine the type traits of the member operator() function then use that to determine the function traits of the functor itself. The two extra specializations will also strip any reference qualifiers to prevent wierd errors.

Like type traits, these function traits are very useful to debug templates. What was once an indecipherable wall of compiler errors can now be easily caught by a single static assertion. As we move on to more complex functional concepts, these will become invaluable.

I leave the implementation of is_callable, which determines if an object is a function or function-like (function pointer, member function/object pointer, functor), to the reader.

Generalized Function Evaluation

I often find myself wishing there was a generalized way of calling functions and function-like “things”.

Functors are obviously quite function-like. Member function pointers can be treated like function where the object pointer as just another parameter. Member object pointers can be treated like a function which retrieves a member from a pointed object.

Now with the new c++11 standard, it is possible to do this quite easily!

#include <type_traits>
#include <utility>

// functions, functors, lambdas, etc.
template<
    class F, class... Args,
    class = typename std::enable_if<!std::is_member_function_pointer<F>::value>::type,
    class = typename std::enable_if<!std::is_member_object_pointer<F>::value>::type
    >
auto eval(F&& f, Args&&... args) -> decltype(f(std::forward<Args>(args)...))
{
    return f(std::forward<Args>(args)...);
}

// const member function
template<class R, class C, class... Args>
auto eval(R(C::*f)() const, const C& c, Args&&... args) -> R
{
    return (c.*f)(std::forward<Args>(args)...);
}

template<class R, class C, class... Args>
auto eval(R(C::*f)() const, C& c, Args&&... args) -> R
{
    return (c.*f)(std::forward<Args>(args)...);
}

// non-const member function
template<class R, class C, class... Args>
auto eval(R(C::*f)(), C& c, Args&&... args) -> R
{
    return (c.*f)(std::forward<Args>(args)...);
}

// member object
template<class R, class C>
auto eval(R(C::*m), const C& c) -> const R&
{
    return c.*m;
}

template<class R, class C>
auto eval(R(C::*m), C& c) -> R&
{
    return c.*m;
}

The first overload of eval covers almost every single case. Furthermore, note the use of universal references and forwarding which automatically handles const and reference qualifiers.

The next three overloads handle const and non-const member function pointers. Additional parameters of C& are added as if they were parameters of the original functions.

Member object pointers are then treated as functions which take a reference to an object then return a reference to its member.

The use of std::enable_if prevents the first overload from greedily instantiating for member function pointers.

Now to show it in action:

#include <iostream>

struct Bloop
{
    int a = 10;
    int operator()(){return a;}
    int operator()(int n){return a+n;}
    int triple(){return a*3;}
};

int add_one(int n)
{
    return n+1;
}

int main()
{
    Bloop bloop;

    // free function
    std::cout << eval(add_one,0) << "\n";

    // lambda function
    std::cout << eval([](int n){return n+1;},1) << "\n";

    // functor
    std::cout << eval(bloop) << "\n";
    std::cout << eval(bloop,4) << "\n";

    // member function
    std::cout << eval(&Bloop::triple,bloop) << "\n";

    // member object
    eval(&Bloop::a,&bloop)++; // increment a by reference
    std::cout << eval(&Bloop::a,bloop) << "\n";

    return 0;
}

Which gives the expected output:

1
2
10
14
30
11

Note: Be careful with pointers to overloaded functions, the compiler will not be able to determine which overload to use. You will need to either explicitly cast to a function pointer or std::function object with the desired type.

Edit: Thank you to STL for pointing out member object pointers should return references, not values.

Edit2: Thanks to Aaron McDaid for pointing out a few more mistakes.