Scala currying vs partially applied functions

Question

I realize that there are several questions on here about what currying and partially applied functions are, but I\'m asking about how they are diff

Answer 1

Currying is to do with tuples: turning a function that takes a tuple argument into one that takes n separate arguments, and vice versa. Remembering this is the key to distinguishing curry vs partial application, even in languages that don't cleanly support currying.

curry :: ((a, b) -> c) -> a -> b -> c 
   -- curry converts a function that takes all args in a tuple
   -- into one that takes separate arguments

uncurry :: (a -> b -> c) -> (a, b) -> c
   -- uncurry converts a function of separate args into a function on pairs.

Partial application is the ability to apply a function to some arguments, yielding a new function for the remaining arguments.

It is easy to remember if you just think currying is the transformation to do with tuples.

In languages that are curried by default (such as Haskell) the difference is clear -- you have to actually do something to pass arguments in a tuple. But most other languages, including Scala, are uncurried by default -- all args are passed as tuples, so curry/uncurry is far less useful, and less obvious. And people even end up thinking that partial application and currying are the same thing -- just because they can't represent curried functions easily!

Answer 2

Multivariable function:

def modN(n: Int, x: Int) = ((x % n) == 0)

Currying (or the curried function):

def modNCurried(n: Int)(x: Int) = ((x % n) == 0)

So it's not partially applied function that's comparable to currying. It's the multivariable function. What's comparable to partially applied function is the invocation result of a curried function, which is a function with the same parameter list that the partially applied function has.

Answer 3

Just to clarify on the last point

Addition: As @asflierl has correctly pointed out, Scala doesn't seem to be able to infer the type when partially applying "normal" functions:

Scala can infer types if all parameters are wildcards but not when some of them are specified and some of them not.

scala> modN(_,_)
res38: (Int, Int) => Boolean = <function2>

scala> modN(1,_)
<console>:13: error: missing parameter type for expanded function ((x$1) => modN(1, x$1))
       modN(1,_)
              ^

Answer 4

The best explanation I could find so far: https://dzone.com/articles/difference-between-currying-amp-partially-applied

Currying: decomposition of functions with multiple arguments into a chain of single-argument functions. Notice, that Scala allows passing a function as an argument to another function.

Partial application of function: pass to a function fewer arguments than it has in its declaration. Scala does not throw an exception when you provide fewer arguments to the function, it simply applies them and returns a new function with rest of arguments that need to be passed.

Answer 5

The semantic difference has been explained fairly well in the answer linked to by Plasty Grove.

In terms of functionality, there doesn't seem much of a difference, though. Let's look at some examples to verify that. First, a normal function:

scala> def modN(n: Int, x: Int): Boolean = ((x % n) == 0)
scala> modN(5, _ : Int)
res0: Int => Boolean = <function1>

So we get a partially applied <function1> that takes an Int, because we've already given it the first integer. So far so good. Now to currying:

scala> def modNCurried(n: Int)(x: Int): Boolean = ((x % n) == 0)

With this notation, you'd naively expect the following to work:

scala> modNCurried(5)
<console>:9: error: missing arguments for method modN;
follow this method with `_' if you want to treat it as a partially applied function
          modNCurried(5)

So the multiple parameter list notation doesn't really seem to create a curried function right away (assumingly to avoid unnecessary overhead) but waits for you to explicitly state that you want it curried (the notation has some other advantages as well):

scala> modNCurried(5) _
res24: Int => Boolean = <function1>

Which is exactly the same thing we got before, so no difference here, except for notation. Another example:

scala> modN _
res35: (Int, Int) => Boolean = <function2>

scala> modNCurried _
res36: Int => (Int => Boolean) = <function1>

This demonstrates how partially applying a "normal" function results in a function that takes all parameters, whereas partially applying a function with multiple parameter lists creates a chain of functions, one per parameter list which, all return a new function:

scala> def foo(a:Int, b:Int)(x:Int)(y:Int): Int = a * b + x - y
scala> foo _
res42: (Int, Int) => Int => (Int => Int) = <function2>

scala> res42(5)
<console>:10: error: not enough arguments for method apply: (v1: Int, v2: Int)Int => (Int => Int) in trait Function2.
Unspecified value parameter v2.

As you can see, because the first parameter list of foo has two parameters, the first function in the curried chain has two parameters.

---

In summary, partially applied functions aren't really different form curried functions in terms of functionality. This is easily verified given that you can convert any function to a curried one:

scala> (modN _).curried
res45: Int => (Int => Boolean) = <function1

scala> modNCurried _
res46: Int => (Int => Boolean) = <function1>

---

Post Scriptum

Note: The reason that your example println(filter(nums, modN(2)) works without the underscore after modN(2) seems to be that the Scala compiler simply assumes that underscore as a convenience for the programmer.

---

Addition: As @asflierl has correctly pointed out, Scala doesn't seem to be able to infer the type when partially applying "normal" functions:

scala> modN(5, _)
<console>:9: error: missing parameter type for expanded function ((x$1) => modN(5, x$1))

Whereas that information is available for functions written using multiple parameter list notation:

scala> modNCurried(5) _
res3: Int => Boolean = <function1>

This answers shows how this can be very useful.