Return to Answer

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 take 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 curried with 1 and this curried function would be passed to r as its function 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 currying 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.

MORE

If f' were called with a q'/r' pair where the q' took more than two arguments, the q' would still end up being curried 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 q was doing in the first place!

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.

MORE

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!

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 take 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 curried with 1 and this curried function would be passed to r as its function 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 currying 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.

MORE

If f' were called with a q'/r' pair where the q' took more than two arguments, the q' would still end up being curried 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 q as a curry-able function was in the first place!

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 take 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 curried with 1 and this curried function would be passed to r as its function 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 currying 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.

MORE

If f' were called with a q'/r' pair where the q' took more than two arguments, the q' would still end up being curried 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 q was doing in the first place!

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 take 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 curried with 1 and this curried function would be passed to r as its function 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 currying 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.

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 take 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 curried with 1 and this curried function would be passed to r as its function 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 currying 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.

MORE

If f' were called with a q'/r' pair where the q' took more than two arguments, the q' would still end up being curried 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 q as a curry-able function was in the first place!