Why does Scala provide both multiple parameters lists and multiple parameters per list?

Multiple parameters lists, e.g. def foo(a:Int)(b:Int) = {} and multiple parameters per list, e.g. def foo(a:Int, b:Int) = {} are semantically equivalent so far as I can tell, and most functional languages have only one way of declaring multiple parameters, e.g. F#.

The only reason I can figure out for supporting both these styles of function definitions is to allow syntax-like language extensions using a parameter list that has only one parameter in it.

def withBufferedWriter(file: File)(block: BufferedWriter => Unit)

can now be called with the syntax-looking

withBufferedWriter(new File("myfile.txt")) { out =>
out write "whatever"
...
}

However, there could be other ways of supporting the use of curly braces without having multiple parameter lists.

A related question: why is the use of multiple parameter lists in Scala called "currying"? Currying is usually defined as a technique for making an n-ary function unary for the sake of supporting partial application. However, in Scala one can partially apply a function without making a "curried" (multiple parameter lists with one param each) version of the function.

30672 次浏览

It makes you able to do e.g.:

scala> def foo(as: Int*)(bs: Int*)(cs: Int*) = as.sum * bs.sum * cs.sum
foo: (as: Int*)(bs: Int*)(cs: Int*)Int


scala> foo(1, 2, 3)(4, 5, 6, 7, 9)(10, 11)
res7: Int = 3906

To answer your "related question," currying is simply a way of turning a function of multiple arguments, for example (A, B, C) => D, into a function which takes one argument and returns a function, e.g. A => (B => (C => D)) (parentheses shown but not necessary).

The tuple-ized form and the curried form are isomorphic, and we may translate freely between them. All of these are equivalent, but have different syntactic implications:

(A, B, C, D, E) => F
((A, B), (C, D, E)) => F
(A, B) => (C, D, E) => F

When you declare separate parameter groups, this is the kind of currying you're doing. The multi-parameter-group method is a method which returns a function... you can see this in the REPL:

scala> def foo(a:Int, b:Int)(c:Int, d:Int, e:Int):Int = 9
foo: (a: Int,b: Int)(c: Int,d: Int,e: Int)Int


scala> foo _
res4: (Int, Int) => (Int, Int, Int) => Int = <function2>

As well as allowing you to write methods that look like part of the language (which you already spotted), it's worth noting that the type inferencer will work with one block at a time.

So in this:

def foo[T](a: T, b: T)(op: (T,T)=>T) = op(a,b)
foo(1,2){_+_}

T will first be inferred as Int, which will then be used as the type of the two underscores in the closure. This is how the compiler then knows, with complete type safety, that the + operation is valid.

I know one of the motivations was implicit parameter lists. "implicit" is a property of the list, not the parameter. Another was probably case classes: only the first parameter list become case fields.

Back references in default arguments:

case class Foo(bar: Int)


def test(f: Foo)(i: Int = f.bar) = i*i


test(Foo(3))()