Mmm, Curry

re: Mmm, Curry

Douglas McClean — Thu, 25 Jun 2009 18:22:18 GMT

...except when T in your last example is a value type, in which case it fails with an Argument Exception: "Error binding to target method," as discussed at http://stackoverflow.com/questions/1016033/extension-methods-defined-on-value-types-cannot-be-used-to-create-delegates-why.

Excellent point; I had forgotten about that. I've updated the text. -- Eric

re: Mmm, Curry

Olmo — Fri, 26 Jun 2009 00:12:56 GMT

Really nice trick, now with extension methods it makes sense to reuse delegate _target field for the first parameter, pretending it's the target object of an instance method.

But the really amazing thing is that you release this in 2004/5, when extension methods didn't exist. Looks like you have an advicer from the future telling you what to do next :)

Nice job

re: Mmm, Curry

Scott — Fri, 26 Jun 2009 00:29:43 GMT

Apparently currying was discovered by Moses Schoenfinkel in 1924, according to http://c2.com/cgi/wiki?CurryingSchonfinkelling

Indeed. It often happens in mathematics that the first discovery or invention of a concept is unappreciated and unknown, and only upon the second discovery does the idea gain currency. There are many examples of this; for example, Benford's Law (which I discussed some time ago in this blog) was originally discovered by Newcombe decades earlier. -- Eric

re: Mmm, Curry

Jon Skeet — Fri, 26 Jun 2009 00:33:41 GMT

I thought that partial application and currying actually had different meanings, and that most people meant "partial application" when they said "currying". Is this not the case after all then?

Indeed, I am speaking informally and imprecisely in this article. "Partial application" is the act of providing too-few arguments to a function so as to somehow get as the result a function of fewer parameters which, when called with the missing arguments, gives the result of calling the original function with all the given arguments. "Currying" is the operation of taking a method of multiple arguments and reorganizing it into several nested methods of a single argument each, so that partial application "starting from the left" can happen easily. The two operations are so naturally a part of the same process that it is easy to conflate them when speaking informally.

re: Mmm, Curry

Strilanc — Fri, 26 Jun 2009 01:27:38 GMT

Before lambda expressions came around I had a library for currying functions. When you called Curry(someFunc, someVar) it created an instance of a class, and returned a delegate to the class' run method, which had one less argument. I also had special curry functions which would do things like take delegates instead of values and only evaluate them at call time.

I was very, very happy when I finally got my hands on VB9. Lambda expressions nuked that entire boring library (90% of the content was copy-paste coding to deal with different numbers of arguments).

I used the library to implement type-safe futures, another very useful abstraction. The futures themselves are relatively boring, the cool part are functions like FutureSub.Call which take normal functions and change them into functions which take and return future arguments.

re: Mmm, Curry

Marcel Popescu — Fri, 26 Jun 2009 11:02:30 GMT

Hmm... I still don't see the "why" part :) Why do this at all? Maybe a more realistic example than "add two numbers in a really convoluted way" is needed :)

re: Mmm, Curry

Masklinn — Fri, 26 Jun 2009 11:37:43 GMT

> In C#, to curry away the first parameter you could simply say

This is not currying, it's partial application. While related concepts they're not the same thing (and your initial link even made the difference between them, though it called partial application the more general concept when clearly it's the other way around).

Currying is the action of turning a function of arity `n` into a sequence of `n` functions of arity 1. Partial application is the action of turning a function of arity `n` into a function of arity `n-k` (with k>0 and commonly 1) by fixing some of its parameters (usually from the front, but not necessarily). You don't curry parameters, you curry functions. So "curry away the first parameters" just doesn't make any sense, while "partially apply" does.

See my reply to Jon's comment above. -- Eric

re: Mmm, Curry

Rene — Fri, 26 Jun 2009 13:58:16 GMT

Probabably variation on the same theme are my "adapters" created for "fun" - some adapters are adopted from the C++ (Bind1st...) , adapter ToPredicate converts Func<T, bool> to Predicate etc.

Automatic translaton of my article (original is only in czech). http://tinyurl.com/mgxlwb (warning: possible syntax errors ( both C# and english) in the article are caused by the translation).

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace FunctionExtensions

{

static class FuncExtension

{

public static Func<T1, R> Bind1St<T0, T1, R>(T0 bindValue, Func<T0, T1, R> originalFunc)

{

return (arg => originalFunc(bindValue, arg));

}

public static Func<T0, R> Bind2nd<T0, T1, R>(T1 bindValue, Func<T0, T1, R> originalFunc)

{

return (arg => originalFunc(arg, bindValue));

}

public static Func<T0, bool> Not<T0>(Func<T0, bool> originalFunc)

{

return (arg => !originalFunc(arg));

}

public static Func<T0, T1, bool> Not<T0, T1>(Func<T0, T1, bool> originalFunc)

{

return ((arg1, arg2) => !originalFunc(arg1, arg2));

}

public static Func<T0, T1, T2, bool> Not<T0, T1, T2>(Func<T0, T1, T2, bool> originalFunc)

{

return ((arg1, arg2, arg3) => !originalFunc(arg1, arg2, arg3));

}

public static Func<T0, T1, bool> And<T0, T1>(Func<T0, T1, bool> originalFunc, Func<T0, T1, bool> originalFunc2)

{

return ((arg1, arg2) => originalFunc(arg1, arg2) && originalFunc(arg1, arg2));

}

public static Func<T0, bool> And<T0>(Func<T0, bool> originalFunc, Func<T0, bool> originalFunc2)

{

return (arg1 => originalFunc(arg1) && originalFunc2(arg1));

}

public static Func<T0, T1, bool> Or<T0, T1>(Func<T0, T1, bool> originalFunc, Func<T0, T1, bool> originalFunc2)

{

return ((arg1, arg2) => originalFunc(arg1, arg2) || originalFunc(arg1, arg2));

}

public static Func<T0, bool> Or<T0>(Func<T0, bool> originalFunc, Func<T0, bool> originalFunc2)

{

return (arg1 => originalFunc(arg1) || originalFunc2(arg1));

}

public static Predicate<T> ToPredicate<T>(Func<T, bool> originalFunc)

{

return arg => originalFunc(arg);

}

re: Mmm, Curry

Olmo — Sat, 27 Jun 2009 00:21:14 GMT

Hi Scott,

My point wasn't that they inveted currification on 2004/5, in fact i think that, when they disigned delegates they weren't thinking in curryfication at all (an academic thing that didn't make a lot of sense in a pre-Linq practical C# language):

Instead they thought that an instance method shouldn't have a different signature than a static one, even if theres an extra parameter (the instance to call), so they hide it and now you can do:

Func<int, int> a = myObject.Method;

Func<int,int> b = MyClass.Method;

This is ok.

The amazing thing though is that they realize that hiding the first parameter could be interesting EVEN it this is not the instance parameter. And then, a few years later Extension methods appear, just a compiler trick to use the first parameter pretending is an instance, and now the feature makes sense.

How C#/CLR guys know that this will happend?

The CLR guys knew that people wanted to implement functional languages on the .NET framework. Consider the problem of using existing methods in a language that emphasizes partial application everywhere. If you are writing new functions, of course you can always curry them to make partial application easier. But if you want to partially apply existing framework methods, then it is helpful to compiler writers to have a way to do that via delegates. It's even nicer if the technique is "baked in" to the framework. That this happened to mesh very nicely with extension methods was a happy accident; my understanding is that their intention was to make it easier for third-party compiler writers. -- Eric