I know I’m getting boring with currying, but I have finished most of what I originally wanted. And I am publishing the code this time. It is published under GPL.

Now, a curried function can be invoked with a single call, like a regular function; in two calls; or in as many calls as you wish - the only limit is the actual number of arguments. So, all of the following works:

f(1, 2, 3, 4, 5, 6)
f(1, 2, 3, 4, 5)(6)
f(1, 2, 3, 4)(5)(6)
f(1, 2)(3)(4)(5, 6)
f(1)(2)(3)(4)(5)(6)

On reddit, a very nice explanation of currying by m42a contained this piece of code:

template <class Func>
auto partially_apply_to_2(Func f)
{
    return uncurry(curry(f)(2));
}

It returns a new function that is same as f, but with the first argument set to 2. (see the post why this is more practical than std::bind). With the new version of curry.h, you don’t even need to uncurry the function, you can just do this:

return curry(f)(2);
// or:
return curry(f, c);

Here are a few documented examples of what you can do:

curry/main.cpp

And here is the header file: curry/curry.h

{% gist 6269914 %}

After my initial post about currying in C++, I was wondering whether it is possible to make a universal curry transformation that will be applicable to any functor.

Fortunately, like most weird things, in C++ the answer to this question is yes.

Here, we’ll create a curry object from a lambda function:

auto log = make_curry(
    [] (int type, int subtype, const std::string & message)
    {
        std::cerr
            << type << " / " << subtype
            << "\t" << message << std::endl;
    }
);

And use it in all the different ways:

int main(int argc, const char *argv[])
{
    auto message = log(1);
    auto error = log(0, 0);

    // Only one argument already given
    message(0, "Normal message");
    message(1, "Important message");

    // We have two arguments already given
    error("No error, just kidding");

    // Or, we can call directly
    log(1, 1, "Arguments: 3 - 0")();
    log(1, 1)("Arguments: 2 - 1");
    log(1)(2, "Arguments: 1 - 2");
    log()(2, 2, "Arguments: 0 - 3");

    return 0;
}

It allows only to split the function arguments into two sets. I might make it a bit more powerful at some point. I’m a bit sleepy now.

Anyone interested in the code?

Currying is all-present in functional programming. And we are not really using it.

What is currying? It is a technique of transforming a function that takes multiple arguments in such a way that it can be called as a chain of functions, each with a single argument.

For example, lets look at a simpler version of fprintf function that looks something like this:

print: (stream, message) -> do something

// Invoked like this:
print(cout, "Hello")

If we use the method often with specific streams (like cout, cerr and a log file), we can define it in a different manner, so that we could easily make additional versions specific to those streams. And, we don’t need to impose our opinions of what a user wants by providing a set of convenience functions ourselves (ok, qDebug() is something that everybody wants, but you get the point).

print: stream -> function called print_to
print_to: message -> do something

// It would be invoked like this:
// (note that the print_to function doesn't
// really need to be named)
print(cout)("Hello")

// or
log = print(logging_stream)
err = print(cerr)

log("Hello")
err("Error world")

So, this seems totally unneeded, right? It can be quite useful when working with generic code (for example STL algorithms). The following example demonstrates vector partitioning for different predicates.

#include <string>
#include <iostream>
#include <algorithm>
#include <iterator>

auto less_than = [] (int i) {
    return [i] (int j) {
        return j < i;
    };
};

template <typename B, typename M, typename E>
inline void write_partitions(B b, M m, E e)
{
    std::copy(b, m, std::ostream_iterator<int>(std::cout, " "));
    std::cout << "  |  ";

    std::copy(m, e, std::ostream_iterator<int>(std::cout, " "));
}

int main(int argc, const char *argv[])
{
    std::vector<int> ns { 1, -2, 3, -4, 5, -6, 7, -8, 9, -10 };

    // Original vector
    std::copy(ns.begin(), ns.end(),
            std::ostream_iterator<int>(std::cout, " "));
    std::cout << " - Original vector" << std::endl;

    // Partitions for numbers ranging from 0 to 9
    for (int i = 0; i < 10; i++) {
        auto p = std::partition(ns.begin(), ns.end(), less_than(i));

        write_partitions(
            ns.begin(),
            p,
            ns.end());
        std::cout << " - Predicate: _ < " << i << std::endl;
    }

    return 0;
}

This is the output it generates:

-10 -2 -8 -4 -6   |  5 7 3 9 1  - Predicate: _ < 0
-10 -2 -8 -4 -6   |  5 7 3 9 1  - Predicate: _ < 1
-10 -2 -8 -4 -6 1   |  7 3 9 5  - Predicate: _ < 2
-10 -2 -8 -4 -6 1   |  7 3 9 5  - Predicate: _ < 3
-10 -2 -8 -4 -6 1 3   |  7 9 5  - Predicate: _ < 4
-10 -2 -8 -4 -6 1 3   |  7 9 5  - Predicate: _ < 5
-10 -2 -8 -4 -6 1 3 5   |  9 7  - Predicate: _ < 6
-10 -2 -8 -4 -6 1 3 5   |  9 7  - Predicate: _ < 7
-10 -2 -8 -4 -6 1 3 5 7   |  9  - Predicate: _ < 8
-10 -2 -8 -4 -6 1 3 5 7   |  9  - Predicate: _ < 9

For Plasma 2, we are aiming to have one plasma to rule them all, but not in the way the others are doing it. We still believe that different form factors need different UIs (I refuse to use UX instead of UI, so sue me :) ). We just want the same application to be able to load the fitting interfaces for the desktop, netbook or tablets. And we want it to be able to dynamically switch between those.

The dynamic switching part I’m working on is almost finished. Namely, everything is prepared for the last step - integrating the new system with the current shells.

Each shell needs the following components: * A simple and lightweight loader object * And an actual shell implementation that can be done as a C++ plugin or a pure QML thing to make it easier for the common people to create the custom ones.

How does it work?

Note: To avoid confusion, from now on when I write Plasma, I mean the plasma-shell executable that loads the actual shells.

Plasma first gets all the loaders. Loaders need to have two properties defined:

• ‘willing’ which tells whether it wants to be loaded for the current environment (for example, Plasma Active shell would say ‘yes’ when we have a touch-screen);
• and ‘priority’ which will allow Plasma to choose between multiple willing shells (for example, an alternative desktop shell that the user installed).

None of these are hard-coded, so a loader can change its mind and, for example, the Desktop shell can set its priority to be as high as possible if we have more than one screen while having a lower one compared to the Active otherwise.

When a suitable shell is found, the loader is requested to create it.

When the environment changes, and the ‘willing’-ness of a loader has been changed, Plasma checks whether it should load a new shell or stick to the old one.

I’ve had an unfortunate situation this week - my system went bust. I’ve been forced to use my netbook for a few days which was rather painful. Fortunately, now it is all over, I’m enjoying a no-swap-ever-needed-8-cpu-core system. Enjoining… if you disregard a very noisy cpu cooler which will need changing.