I've been reading articles on Functional programming everyday and been trying to apply some practices as much as possible. But I don't understand what is unique in currying or partial application.

Take this Groovy code as an example:

def mul = { a, b -> a * b }
def tripler1 = mul.curry(3)
def tripler2 = { mul(3, it) }

I do not understand what is the difference between tripler1 and tripler2. Aren't they both the same? The 'currying' is supported in pure or partial functional languages like Groovy, Scala, Haskell etc. But I can do the same thing (left-curry, right-curry, n-curry or partial application) by simply creating another named or anonymous function or closure that will forward the parameters to the original function (like tripler2) in most languages (even C.)

Am I missing something here? There are places where I can use currying and partial application in my Grails application but I am hesitating to do so because I'm asking myself "How's that different?"

Please enlighten me.

EDIT: Are you guys saying that partial application/currying is simply more efficient than creating/calling another function that forwards default parameters to original function?

  • 1
    Can somebody please create the tags "curry" or "currying"? Nov 27, 2012 at 12:18
  • How do you curry in C?
    – Giorgio
    Nov 27, 2012 at 12:24
  • this is probably really more about partial application programmers.stackexchange.com/questions/152868/…
    – jk.
    Nov 27, 2012 at 12:33
  • 1
    @Vigneshwaran: AFAIK you do not need to create another function in a language supporting currying. For example, in Haskell f x y = x + y means that f is a function that takes one int parameter. The result of f x (f applied to x) is a function that takes one int parameter. The result f x y (or (f x) y, i.e. f x applied to y) is an expression that takes no input parameters and is evaluated by reducing x + y.
    – Giorgio
    Nov 27, 2012 at 12:48
  • 1
    You can achieve the same things, but the amount of effort you go through with C is much more painful and not as efficient as in a language like haskell where it's the default behavior Nov 27, 2012 at 12:57

4 Answers 4


Currying is about turning/representing a function which takes n inputs into n functions that each take 1 input. Partial application is about fixing some of the inputs to a function.

The motivation for partial application is primarily that it makes it easier to write higher order function libraries. For instance the algorithms in C++ STL all largely take predicates or unary functions, bind1st allows the library user to hook in non unary functions with a value bound. The library writer therfore does not need to provide overloaded functions for all algorithms that take unary functions to provide binary versions

Currying itself is useful because it gives you partial application anywhere you want it for free i.e. you no longer need a function like bind1st to partially apply.

  • is currying something specific to groovy or applicable across languages?
    – amphibient
    Nov 27, 2012 at 16:02
  • @foampile its something that is applicable across languages, but ironically groovy curry doesn't really do it programmers.stackexchange.com/questions/152868/…
    – jk.
    Nov 27, 2012 at 16:05
  • @jk. Are you saying that currying/partial application is more efficient than creating and calling another function? Nov 28, 2012 at 7:39
  • 2
    @Vigneshwaran - it is not necessarily more performant, but it is definitely more efficient in terms of the programmer's time. Also note that while currying is supported by many functional languages, but is generally not supported in OO or procedural languages. (Or at least, not by the language itself.)
    – Stephen C
    Nov 28, 2012 at 10:54

But I can do the same thing (left-curry, right-curry, n-curry or partial application) by simply creating another named or anonymous function or closure that will forward the parameters to the original function (like tripler2) in most languages (even C.)

And the optimizer will look at that and promptly go on to something it can understand. Currying is a nice little trick for the end user, but has much better benefits from a language design standpoint. It's really nice to handle all methods as unary A -> B where B may be another method.

It simplifies what methods you have to write to handle higher order functions. Your static analysis and optimization in the language only has one path to work with that behaves in a known manner. Parameter binding just falls out of the design rather than requiring hoops to do this common behavior.


As @jk. alluded to, currying can help make code more general.

For example, suppose you had these three functions (in Haskell):

> let q a b = (2 + a) * b

> let r g = g 3

> let f a b = b (a 1)

The function f here takes two functions as arguments, passes 1 to the first function and passes the result of the first call to the second function.

If we were to call f using q and r as the arguments, it'd effectively be doing:

> r (q 1)

where q would be applied to 1 and return another function (as q is curried); this returned function would then be passed to r as its argument to be given an argument of 3. The result of this would be a value of 9.

Now, let's say we had two other functions:

> let s a = 3 * a

> let t a = 4 + a

we could pass these to f as well and get a value of 7 or 15, depending on whether our arguments were s t or t s. Since these functions both return a value rather than a function, no partial application would take place in f s t or f t s.

If we had written f with q and r in mind we might have used a lambda (anonymous function) instead of partial application, e.g.:

> let f' a b = b (\x -> a 1 x)

but this would have restricted the generality of f'. f can be called with arguments q and r or s and t, but f' can only be called with q and r -- f' s t and f' t s both result in an error.


If f' were called with a q'/r' pair where the q' took more than two arguments, the q' would still end up being partially applied in f'.

Alternatively, you could wrap q outside of f instead of inside, but that'd leave you with a nasty nested lambda:

f (\x -> (\y -> q x y)) r

which is essentially what the curried q was in the first place!

  • You opened my eyes. Your answer made me realize how curried/partially applied functions are different from creating a new function that passes arguments to the original function. 1. Passing around curryied/p.a.ed functions (like f(q.curry(2)) are neater than creating separate functions unnecessarily for just a temporary use. (in functional languages like groovy) Nov 30, 2012 at 6:00
  • 2. In my question, I said, "I can do the same in C." Yes, but in non-functional languages, where you can't pass around functions as data, creating a separate function, that forwards parameters to original, does not have all the benefits of currying/p.a. Nov 30, 2012 at 6:01
  • I noticed that Groovy doesn't support the type of generalization Haskell supports. I had to write def f = { a, b -> b a.curry(1) } to make f q, r to work and def f = { a, b -> b a(1) } or def f = { a, b -> b a.curry(1)() } for f s, t to work. You have to pass all the parameters or explicitly say you're currying. :( Nov 30, 2012 at 6:11
  • 2
    @Vigneshwaran: Yes, it's safe to say that Haskell and currying go together very well. ;] Note that in Haskell, functions are curried (in the correct definition) by default and whitespace indicates function application, so f x y means what many languages would write f(x)(y), not f(x, y). Perhaps your code would work in Groovy if you write q so that it expects to be called like q(1)(2)? Nov 30, 2012 at 15:55
  • 1
    @Vigneshwaran Glad I could help! I feel your pain about having to explicitly say you're doing partial application. In Clojure I have to do (partial f a b ...) -- being used to Haskell, I miss proper currying a lot when programming in other languages (though I've been working recently in F# which, thankfully, supports it).
    – paul
    Nov 30, 2012 at 17:37

There are two key points about partial application. The first is syntactic/convenience -- some definitions become easier and shorter to read and write, as @jk mentioned. ( Check out Pointfree programming for more about how awesome this is! )

The second, as @telastyn mentioned, is about a model of functions and is not merely convenient. In the Haskell version, from which I'll get my examples because I'm not familiar with other languages with partial application, all functions take a single argument. Yes, even functions like:

(:) :: a -> [a] -> [a]

take a single argument; because of the associativity of the function type constructor ->, the above is equivalent to:

(:) :: a -> ([a] -> [a])

which is a function that takes an a and returns a function [a] -> [a].

This allows us to write functions like:

($) :: (a -> b) -> a -> b

which can apply any function to an argument of the appropriate type. Even crazy ones like:

f :: (t, t1) -> t -> t1 -> (t2 -> t3 -> (t, t1)) -> t2 -> t3 -> [(t, t1)]
f q r s t u v = q : (r, s) : [t u v]

f' :: () -> Char -> (t2 -> t3 -> ((), Char)) -> t2 -> t3 -> [((), Char)]
f' = f $ ((), 'a')  -- <== works fine

Okay, so that was a contrived example. But a more useful one involves the Applicative type class, which includes this method:

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

As you can see, the type is identical similar to $ if you take away the Applicative f bit, and in fact, this class describes function application in a context. So instead of normal function application:

ghci> map (+3) [1..5]  

We can apply functions in an Applicative context; for example, in the Maybe context in which something may be either present or missing:

ghci> Just map <*> Just (+3) <*> Just [1..5]
Just [4,5,6,7,8]

ghci> Just map <*> Nothing <*> Just [1..5]

Now the really cool part is that the Applicative type class doesn't mention anything about functions of more than one argument -- nevertheless, it can deal with them, even functions of 6 arguments like f:

fA' :: Maybe (() -> Char -> (t2 -> t3 -> ((), Char)) -> t2 -> t3 -> [((), Char)])
fA' = Just f <*> Just ((), 'a')

As far as I know, the Applicative type class in its general form would not be possible without some conception of partial application. (To any programming experts out there -- please correct me if I'm wrong!) Of course, if your language lacks partial application, you could build it in in some form, but ... it's just not the same, is it? :)

  • 1
    Applicative without currying or partial application would use fzip :: (f a, f b) -> f (a, b). In a language with higher-order functions, this lets you lift currying and partial application into the functor's context and is equivalent to (<*>). Without higher-order functions you won't have fmap so the whole thing would be useless. Nov 30, 2012 at 16:06
  • @C.A.McCann thanks for the feedback! I knew I was in over my head with this answer. So is what I said wrong?
    – user39685
    Nov 30, 2012 at 16:37
  • 1
    It's correct in spirit, certainly. Splitting hairs over the definitions of "general form", "possible", and having a "conception of partial application" won't change the simple fact that the charming f <$> x <*> y idiomatic style works easily because currying and partial application work easily. In other words, what's pleasant is more important than what's possible here. Nov 30, 2012 at 16:53
  • Every time I see code examples of functional programming, I'm more convinced it's an elaborate joke and that it doesn't exist.
    – Kieveli
    Dec 11, 2013 at 17:00
  • 1
    @Kieveli it's unfortunate you feel that way. There are many fine tutorials out there that will get you up and running with a good understanding of the basics.
    – user39685
    Dec 11, 2013 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.