C# Linq vs. Currying

Question

I am playing a little bit with functional programming and the various concepts of it. All this stuff is very interesting. Several times I have read about Currying and what an advantage it has.

But I do not get the point with this. The following source demonstrates the using of the curry concept and the solution with linq. Actually, I do not see any advatages of using the currying concept.

So, what is the advantage of using currying?

static bool IsPrime(int value)
{
    int max = (value / 2) + 1;
    for (int i = 2; i < max; i++)
    {
        if ((value % i) == 0)
        {
            return false;
        }
    }
    return true;
}

static readonly Func<IEnumerable<int>, IEnumerable<int>> GetPrimes = 
        HigherOrder.GetFilter<int>().Curry()(IsPrime);

static void Main(string[] args)
{
    int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 };

    Console.Write("Primes:");
    //Curry
    foreach (int n in GetPrimes(numbers))
    {
        Console.Write(" {0}", n);
    }
    Console.WriteLine();

    //Linq
    foreach (int n in numbers.Where(p => IsPrime(p)))
    {
        Console.Write(" {0}", n);
    }

    Console.ReadLine();
}

Here is the HigherOrder Filter Method:

public static Func<Func<TSource, bool>, IEnumerable<TSource>, IEnumerable<TSource>> GetFilter<TSource>()
{
    return Filter<TSource>;
}

Answer 1

what is the advantage of using currying?

First off, let's clarify some terms. People use "currying" to mean both:

1. reformulating a method of two parameters into a methods of one parameter that returns a method of one parameter and
2. partial application of a method of two parameters to produce a method of one parameter.

Clearly these two tasks are closely related, and hence the confusion. When speaking formally, one ought to restrict "currying" to refer to the first definition, but when speaking informally either usage is common.

So, if you have a method:

static int Add(int x, int y) { return x + y; }

you can call it like this:

int result = Add(2, 3); // 5

You can curry the Add method:

static Func<int, int> MakeAdder(int x) { return y => Add(x, y); }

and now:

Func<int, int> addTwo = MakeAdder(2);
int result = addTwo(3); // 5

Partial application is sometimes also called "currying" when speaking informally because it is obviously related:

Func<int, int> addTwo = y=>Add(2,y);
int result = addTwo(3);

You can make a machine that does this process for you:

static Func<B, R> PartiallyApply<A, B, R>(Func<A, B, R> f, A a)
{
    return (B b)=>f(a, b);
}
...
Func<int, int> addTwo = PartiallyApply<int, int, int>(Add, 2);
int result = addTwo(3); // 5

So now we come to your question:

what is the advantage of using currying?

The advantage of either technique is that it gives you more flexibility in dealing with methods.

For example, suppose you are writing an implementation of a path finding algorithm. You might already have a helper method that gives you an approximate distance between two points:

static double ApproximateDistance(Point p1, Point p2) { ... }

But when you are actually building the algorithm, what you often want to know is what is the distance between the current location and a fixed end point. What the algorithm needs is Func<Point, double> -- what is the distance from the location to the fixed end point? What you have is Func<Point, Point, double>. How are you going to turn what you've got into what you need? With partial application; you partially apply the fixed end point as the first argument to the approximate distance method, and you get out a function that matches what your path finding algorithm needs to consume:

Func<Point, double> distanceFinder = PartiallyApply<Point, Point, double>(ApproximateDistance, givenEndPoint);

If the ApproximateDistance method had been curried in the first place:

static Func<Point, double> MakeApproximateDistanceFinder(Point p1) { ... }

Then you would not need to do the partial application yourself; you'd just call MakeApproximateDistanceFinder with the fixed end point and you'd be done.

Func<Point, double> distanceFinder = MakeApproximateDistanceFinder(givenEndPoint);

Answer 2

The comment by @Eric Lippert on What is the advantage of Currying in C#? (achieving partial function) points to this blog post:

Currying and Partial Function Application

Where I found this the best explantion that works for me:

From a theoretical standpoint, it is interesting because it (currying) simplifies the lambda calculus to include only those functions which have at most one argument. From a practical perspective, it allows a programmer to generate families of functions from a base function by fixing the first k arguments. It is akin to pinning up something on the wall that requires two pins. Before being pinned, the object is free to move anywhere on the surface; however, when when first pin is put in then the movement is constrained. Finally, when the second pin is put in then there is no longer any freedom of movement. Similarly, when a programmer curries a function of two arguments and applies it to the first argument then the functionality is limited by one dimension. Finally, when he applies the new function to the second argument then a particular value is computed.

Taking this further I see that functional programming essentially introduces 'data flow programming as opposed to control flow' this is akin to using say SQL instead of C#. With this definition I see why LINQ is and why it has many many applications outside of pure Linq2Objects - such as events in Rx.

Answer 3

The advantage of using currying is largely to be found in functional languages, which are built to benefit from currying, and have a convenient syntax for the concept. C# is not such a language, and implementations of currying in C# are usually difficult to follow, as is the expression HigherOrder.GetFilter<int>().Curry()(IsPrime).