Understanding Currying in Scala

Question

I\'m getting problems to understand the currying concept, or at least the SCALA currying notation.

wikipedia says that currying is the technique of translating the evalu

Answer 1

They have a bit different semantics, but their use-cases are mostly the same, both practically and how it looks in the code.

Currying

Currying a function in Scala in that mathematical sense is a very straightforward:

val function = (x: Int, y: Int, z: Int) => 0
// function: (Int, Int, Int) => Int = 
function.curried
// res0: Int => (Int => (Int => Int)) = 

Functions & methods

You seem to be confused by the fact that in Scala, (=>) functions are not the same as (def) methods. Method isn't a first-class object, while function is (i.e. it has curried and tupled methods, and Function1 has even more goodness).

Methods, however, can be lifted to functions by an operation known as eta expansion. See this SO answer for some details. You can trigger it manually by writing methodName _, or it will be done implicitly if you give a method to where a function type is expected.

def sumAndAdd4(i: Int, j: Int) = i + j + 4
// sumAndAdd4.curried // <- won't compile

val asFunction = sumAndAdd4 _ // trigger eta expansion
// asFunction: (Int, Int) => Int = 
val asFunction2: (Int, Int) => Int = sumAndAdd4
// asFunction2: (Int, Int) => Int = 
val asFunction3 = sumAndAdd4: (Int, Int) => Int
// asFunction3: (Int, Int) => Int = 


asFunction.curried
// res0: Int => (Int => Int) = 
asFunction2.curried
// res1: Int => (Int => Int) = 
asFunction3.curried
// res2: Int => (Int => Int) = 
{sumAndAdd4 _}.tupled // you can do it inline too
// res3: Int => (Int => Int) = 

Eta expansion of multiple parameter list

Like you might expect, eta expansion lifts every parameter list to its own function

def singleArgumentList(x: Int, y: Int) = x + y
def twoArgumentLists(x: Int)(y: Int) = x + y

singleArgumentList _ // (Int, Int) => Int
twoArgumentLists _ // Int => (Int => Int) - curried!

val testSubject = List(1, 2, 3)

testSubject.reduce(singleArgumentList) // Int (6)
testSubject.map(twoArgumentLists) // List[Int => Int]

// testSubject.map(singleArgumentList) // does not compile, map needs Int => A
// testSubject.reduce(twoArgumentLists) // does not compile, reduce needs (Int, Int) => Int

But it's not that currying in mathematical sense:

def hmm(i: Int, j: Int)(s: String, t: String) = s"$i, $j; $s - $t"

{hmm _} // (Int, Int) => (String, String) => String

Here, we get a function of two arguments, returning another function of two arguments.

And it's not that straightforward to specify only some of its argume

val function = hmm(5, 6) _ // <- still need that underscore!

Where as with functions, you get back a function without any fuss:

val alreadyFunction = (i: Int, j: Int) => (k: Int) => i + j + k

val f = alreadyFunction(4, 5) // Int => Int

---

Do which way you like it - Scala is fairly un-opinionated about many things. I prefer multiple parameter lists, personally, because more often than not I'll need to partially apply a function and then pass it somewhere, where the remaining parameters will be given, so I don't need to explicitly do eta-expansion, and I get to enjoy a terser syntax at method definition site.