On 22/04/2012 11:40 AM, Warp wrote:

>    But that's the thing: It sounds so trivial as to defy sense. Why give
> a particular name to such a trivial thing?

One could argue that "calling a function" is a pretty trivial idea. But 
it's still useful to have a name for it.

>    But then when one starts asking questions like "so it's like giving
> default values to function parameters?" or "so it's like writing another
> function with less parameters that calls the first function by giving it
> some default values as the rest of the parameters?", the answer is something
> like "not really".

Providing default arguments is /kind of/ similar. The difference is that 
usually you /can/ still provide explicit values which override the 
defaults. With a curried function, you /cannot/ change the arguments 
that have already been given. (Or even know if any arguments /have/ been 
give yet. All you can see is what arguments remain.)

Writing a new function that takes one fewer arguments than an existing 
one is like currying. Except that the idea behind "currying" is that 
this is /automatic/. You don't have to code it yourself. It's 
automatically available for all functions.

Finally, like I said, currying works backwards too: If a function call 
happens to return a function as its result, you can just keep appending 
arguments. "head function_list 7" and all that.

Curried functions mean that, at the language level, there is 
fundamentally no difference between taking several arguments, and 
functions that return functions that return functions.

As you say, it's /not/ an especially wild concept. But it's [usually] 
not a feature that you can add without changing the language design.

That said, you could probably design some sort of object that has 
methods for adding arguments, N at a time, and when it gets enough 
arguments, it yields an answer. And that might reasonably be described 
as currying.

Post a reply to this message