2

Sorry if this is going over old ground. I realize that this has been [discussed before] What is the difference between currying and partial application?. I would still like some clarification about terminology.

Is it fair to say that currying enables partial application and that partial application is not possible on functions that had not been curried? Is it also fair to say that in languages like Haskell that support partial application automatically, all functions are implicitly curried?

Community
  • 1
  • 1
RussAbbott
  • 2,660
  • 4
  • 24
  • 37

1 Answers1

2

Both currying and partial application imply that a language supports higher-order functions--that is, passing functions around as data--since they'd be useless otherwise, and using higher-order functions, both currying and partial application can be implemented manually.

Aside from the above, they're separate ideas.

Would you say that having a while loop "enables" for or foreach loops? In some sense that's true, but it tells you nothing useful about the loops.

Partial application means exactly what it says; you apply a function to some of its arguments, producing a specialized version that only needs the remaining arguments. This can be done with or without currying the function, perhaps using a wrapper function to juggle arguments around like apply_foo_to_baz(baz) = ((bar, quux) => foo(bar, baz, quux));, if you'll pardon the pseudocode.

Currying means converting a function that takes multiple parameters like foo1(bar, baz, quux); into one that is applied to a single argument at a time, like foo2(bar)(baz)(quux);. Applying foo2 to fewer arguments is technically not partial application, because the function only takes one argument. Knowing that foo2 is a curried version of foo1, we can think of foo2(bar) as being a partially-applied form of foo1, but there's nothing about curried functions in general that make them "partially applied" given any particular number of arguments.

As far as Haskell is concerned, functions defined in the usual way are actually curried by default (which is fitting, since both are named after the same person). In fact, it's actually a bit tricky to usefully define what "partial application" means in Haskell without relying on implementation details.

C. A. McCann
  • 76,893
  • 19
  • 209
  • 302
  • I am concluding that your answer to my second question (Is it fair to say that in languages like Haskell that support partial application automatically, all functions are implicitly curried?) is "yes". – RussAbbott Oct 18 '12 at 22:48
  • @RussAbbott: More like "it's the other way around", but yeah. Haskell and similar languages curry things by default, and *because* of that partial application is easier (unless you want to, say, partially apply only the third argument, heh). – C. A. McCann Oct 18 '12 at 22:55
  • Your pseudo code example of partial application [apply_foo_to_baz(baz) = ((bar, quux) => foo(bar, baz, quux))] makes it sound like partial application is nothing special. For any function f(a_param, b_param, c_param) I can write g(f, a_arg) = ((b, c) => f(a_arg, b, c)). All g does is to create a function that stores the value of a_arg and plugs it in for a_param in a call to f. That's useful, but is it really worthy of a name like "partial application?" No real application has occurred. All that has happened is that one of the arguments has been cached. – RussAbbott Oct 18 '12 at 22:58
  • @RussAbbott: Well, that's a matter of implementation--a compiler could optimize it, much like it could evaluate constant arithmetic expressions ahead of time. But otherwise, you're right--it's nothing special, assuming a language supports higher-order functions at all. That's probably why the term is as boringly literal as "partial application". – C. A. McCann Oct 18 '12 at 23:33