Groovy's implementation of curry
does not actually curry at any point, even behind the scenes. It is essentially identical to partial application.
The curry
, rcurry
and ncurry
methods return a CurriedClosure
object that holds the bound arguments. It also has a method getUncurriedArguments
(misnamed—you curry functions, not arguments) which returns the composition of the arguments passed to it with the bound arguments.
When a closure gets called, it ultimately calls the invokeMethod
method of MetaClassImpl
, which explicitly checks to see if the calling object is an instance of CurriedClosure
. If so, it uses the aforementioned getUncurriedArguments
to compose the full array of arguments to apply:
if (objectClass == CurriedClosure.class) {
// ...
final Object[] curriedArguments = cc.getUncurriedArguments(arguments);
// [Ed: Yes, you read that right, curried = uncurried. :) ]
// ...
return ownerMetaClass.invokeMethod(owner, methodName, curriedArguments);
}
Based on the confusing and somewhat inconsistent nomenclature above, I suspect that whoever wrote this has a good conceptual understanding, but was perhaps a little rushed and—like many smart people—conflated currying with partial application. This is understandable (see Paul King's answer), if a little unfortunate; it will be difficult to correct this without breaking backwards compatibility.
One solution I've suggested is to overload the curry
method such that when no arguments are passed it does real currying, and deprecate calling the method with arguments in favour of a new partial
function. This might seem a little strange, but it would maximise backwards compatibility—since there's no reason to use partial application with zero arguments—while avoiding the (IMHO) uglier situation of having a new, differently-named function for proper currying while the function actually named curry
does something different and confusingly similar.
It goes without saying that the result of calling curry
is completely different from actual currying. If it really curried the function, you would be able to write:
def add = { x, y -> x + y }
def addCurried = add.curry() // should work like { x -> { y -> x + y } }
def add1 = addCurried(1) // should work like { y -> 1 + y }
assert add1(1) == 2
…and it would work, because addCurried
should work like { x -> { y -> x + y } }
. Instead it throws a runtime exception and you die a little inside.