Lambdas and Closures and Currying. Oh my! (Part 8)

We are now finally back for Part 8 of my functional programming series. In this part of my series we are going to be discussing currying in C# 3.0. Currying is actually a mathematical term where you take a function with multiple parameters and turn it into a function with only one parameter. This is done by simply providing values for the parameters that you want to take away. You are probably thinking "Well, that is pretty simple." And quite frankly, the concept is simple. The execution gets a bit more tricky, but it isn’t too bad. Especially if you have made it through this whole series.

Just like most of our other entries in this series, we are going to start off with a two argument multiply method to get our gears turning. This method looks like this:

  public static int Multiply(int a, int b)

  {

    return a * b;

  }

Now, our end goal is to supply a value for one of our arguments in order to make a function that only takes a single argument. So, the way we will do that is by creating an extension method that will operate on a two parameter delegate and will return a method which takes one parameter (This is our curried method). This new method will then take that parameter and return a new method that takes a single parameter, using the parameter that we passed to our curried method (this method is said to be "partially applied"). It sounds a lot more complex than it is, so lets first look at the usage to clear up what I said above.

  //Put Multiply method into a delegate so we can use

  //our extension method

  Func<int, int, int> method = Multiply;

  //Now curry our Multiply method

  var curriedMultiply = method.Curry();

  //Use the curried method to create 

  //partially applied methods

  var doubler = curriedMultiply(2);

  int result1 = doubler(5);

  int result2 = doubler(10);

Hopefully that made what I was saying much more clear. Our curried method just generates partially applied methods. So in this case we generated a doubler, but we could have also generated a tripler or quadrupler. Lets look at the method that generates this method:

  public static Func<TArg1, Func<TArg2, TResult>> 

    Curry<TArg1, TArg2, TResult>

    (this Func<TArg1, TArg2, TResult> func)

  {

    return argument1 => argument2 => func(argument1, argument2);

  }

Let’s break this down so it doesn’t look so crazy. First lets look at "Curry<TArg1, TArg2, TResult>" which is actually the generic method signature. This tells us that we have two arguments and a result type that need to be specified. In our case it is <int,int,int>. The extension method just takes a Func delegate with the same generic parameters as our method signature. Our multiply method works fine because it takes two args. The return type "Func<TArg1, Func<TArg2, TResult>>" is the interesting part. This just says that our extension method is returning a delegate that takes one parameter "TArg1" and then returns another delegate that also takes one parameter.

We accomplish this return type by chaining two lambdas together as you can see above. It may look weird, but argument1 and argument2 are just integer parameters. The inside lambda takes one parameter and returns a closure that is bound to argument2 from the outer lambda (Go back and check out earlier posts in the series for info on closures). So what you end up with is the outer lambda taking one parameter and then returning a closure that uses that parameter. It may look a bit more intuitive if I write it like this:

  public static Func<TArg1, Func<TArg2, TResult>> 

    Curry<TArg1, TArg2, TResult>

    (this Func<TArg1, TArg2, TResult> func)

  {

    return (TArg1 argument1) => {

      return (TArg2 argument2) =>

      {

        return func(argument1, argument2);

      };

    };

  }

Personally I think the lambda syntax is actually easier to read, but you should do what is the most clear for you and your team. In this new, updated version you can more clearly see that we are returning a closure that returns a closure that returns the result of our "func" method. So, the caller to our method will end up with a reference to the outermost closure.

So, now that we have succeeded in creating our curry method we have to ask ourselves, "do we really need it?" Instead of creating this curried method that generates all of our other methods, wouldn’t it just be easier to pass our initial value to the curry method and get back a partially applied method right away? And the answer in this case is, yes, it would be. To do this we are going to create a method called "PartiallyApply." Here is how we are going to use this method:

  Func<int, int, int> method = Multiply;

  //Create our partially applied method

  var doubler = method.PartiallyApply(2);

  int result1 = doubler(5);

  int result2 = doubler(10);

Essentially we are just turning it into one step. We are passing our value into the "PartiallyApply" method and we are getting back a method that can be called immediately to get a value. This method looks like this:

  public static Func<TArg2, TResult> 

    PartiallyApply<TArg1, TArg2, TResult>

    (this Func<TArg1, TArg2, TResult> func, TArg1 argument1)

  {

    return argument2 => func(argument1, argument2);

  }

Here we are just passing in a delegate and a single argument, then we call our delegate with the value of the argument we passed in and return a method that takes the additional argument. This is much easier to use than our Curry method, and so you may be wondering why we would need the currying to begin with. Well, it all starts to become apparent when you graduate beyond two parameters.

This post is starting to get a bit a bit long-winded, so I am going to go ahead and stop there. We have seen how currying and partial application work in two parameters, and so far they seem to be very similar only that the currying seems to involve this useless middle step. When we return with Part 9 we are going to move beyond two parameters and show you why currying and partial application really aren’t as alike as they may seem right now. So stay tuned!