Tracking Election Promises with Scala and Play!

A few months ago I decided to learn Scala because it looked like an interesting, type-safe, concise and multiparadigmatic programming language. And all the cool kids were talking about it. At the same time, about two months before last year’s elections to the German parliament, my internet friend and journalist Jan Falk had the idea to build a German version of the Obameter tracking the campaign promises of the next German government.

Thus, the wahlversprechen project was born. A Scala and Play! based web application. Today, about 6 weeks after the new government formed, the complete coalition treaty signed by the two governing parties is online as are the campaign promises by both governing parties, the Social Democracts and the Christian Democrats.

We itemized the election programs as well as the coalition treaty and identified the promises that can be rated as kept or broken, i.e., the promises that are precise enough that failing to implement them is actually possible. The election promises are categorized based on the responsible Ministry, they are tagged and searchable.

Each election promise has its own page which shows how it has been rated (i.e. if the promise has been rated as a kept promise, a broken one, if it has stalled, or is in progress), the relevant quote from the election program and the editorial updates linking to press reports or even the passed law. To let interested users and readers contribute their opinions or even updates on the state of some promises, each election promise page has its own Disqus comment thread.

The start page shows at a glance how many promises have been kept, were broken, or ended in compromise:

Progress Bar on Start Page

To import long lists of itemized election promises the application is able to import Google Spreadsheets. Site editors can post editorial updates, change the tags or fix typos via the web interface of course (Note the Markdown syntax in the source of the quote):

Editing View for Election Promises

What’s next?

There are a couple of todo items pretty high on my list:

  • The site needs some (JSON) export to free the data we have assembled
  • All templates are in German at the moment and need some internationalization. (The code is in English of course as it should be)
  • I’ve already started work on a news aggregator that tries to identify the election promises the media are currently talking about through simple statistics. The code is on github and it is already working pretty well.

What can you do?

Well glad you asked!

  • Use it as a reference and tell me if it works!
  • Tell me and the team if anything important is missing.
  • Comment, help us do the research and follow the news.
  • Run your own instance and track other elections!
  • Fork it & improve it!

Most of all, tell me if you find it useful. That always makes my day.

Better Function Objects in C++11

At the 2013 Meeting C++ conference, Eric Niebler argued in his keynote that we should be using function objects more often in C++. If I recall correctly, his argument was that function objects don’t participate in ADL.

Function objects have another advantage. They are easier to use in std::bind. If you pass a function pointer or a pointer to a member function to std::bind et al, you have to specify the exact function overload. Given

template<class T> 
struct foo {
    int bar(int a, int b) const { ... }
    int bar(int a, int b) { ... }

the following statement creates a unary function that takes an int x as argument and calls the const overloaded member function, x) on that instance:

foo<int> f;
auto fn_bar = std::bind(
    static_cast< int (foo<int>::*)(int, int) const >(
    f, 0, std::placeholders::_1

Eric advocated writing function objects like this instead:

struct bar_ {
    template<typename Foo>
    auto operator()(Foo&& foo, int a, int b) const 
        -> decltype(, b)) 
        return, b);
} bar;

The above bind can now be written as:

auto fn_bar = std::bind(bar, f, 0, std::placeholders::_1);

Much better. But wouldn’t it be better still if we could create a unary function object by writing

auto fn_bar = bar(f, 0, std::placeholders::_1); // 1

or even — let’s go crazy — by writing this:

auto fn_bar = bar(f, 0); // 2

Since bar is a ternary function that is only called with two arguments, it turns into a unary function fn_bar. Calling fn_bar(1) expands to bar(f, 0, 1). That is called currying and is supported e.g. in Scala and other functional programming languages.

All we need for this to work is a wrapper around our struct bar_ that can detect at compile time if

  1. bar is called with arguments that contain a std::placeholder
  2. bar is called with too few arguments

In these cases the object returned from a call to bar is actually a std::bind object, i.e. a function object. The first style of self-binding function objects has been implemented by Eric as part of his (experimental) range library. I’ve implemented the second style of function objects that automatically curry when the number of arguments is too low.

Eric’s imple
mentation supports chained function objects, it seems, i.e. calling f(g(std::placeholders::_1), 1, 2) should become a unary function. I didn’t get to that.

While I like the idea of leaving out the placeholders too, my own approach suffers from a serious drawback at the moment. My solution is, like Eric’s, based on std::bind and that needs to be passed the desired number of placeholders. Therefore my function object wrapper needs to know how many placeholders to pass to std::bind when it is called with n arguments. That means my function wrapper needs to know the arity of the wrapped function. There is no way to determine the arity of struct bar_ at compile time. bar_ could overload operator() of course with different numbers of arguments, so there isn’t a defined single function arity to begin with.

The solution: Remove my dependency on std::bind.

To be continued