81

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.

Jacek Laskowski
  • 72,696
  • 27
  • 242
  • 420
Yuvi Masory
  • 2,644
  • 2
  • 27
  • 36
  • In general: it's simply more mathematically expressive. Why suffice with one list when you can generalize to a plurality :) – matanster Sep 26 '15 at 21:33

5 Answers5

81

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
Knut Arne Vedaa
  • 15,372
  • 11
  • 48
  • 59
  • 2
    One limitation of this is that, although you have a variable length for each parameter group, the number of groups must be fixed (in this case, at 3). – Tom Crockett Jan 13 '11 at 21:22
  • 30
    Since you have accepted this answer, it should be noted that this is just an example and might not be the canonical answer to your "why" question. – Knut Arne Vedaa Jan 14 '11 at 09:25
  • 1
    This is the first concrete reason I have seen to date for having both types of parameters. All the others are quite ad hoc. That said, I still don't see any of these reasons as worth the syntactic baggage and complication of the language. – Yuvi Masory Jan 14 '11 at 16:14
  • 3
    It's quite unavoidable that you have the option of curried functions in a language that supports both function types and tuples. The only question is whether you provide a little extra syntax sugar for declaring them, which is all the "parameter group" syntax is. Without it, you could do essentially the same thing, but you'd have to type a little more: `def foo[A, B, C, D, E](a:A, b:B) = (c:C, d:D) => (e:E) => ...` – Tom Crockett Jan 14 '11 at 23:42
  • 3
    It might not be obvious to everyone what your example shows. Maybe 2 setences of explaination would do wonders. – Th 00 mÄ s Dec 08 '14 at 13:02
  • What's the point? Optional arguments? – shinzou Nov 07 '17 at 12:00
  • Multiple varargs. Until now a pipe dream. So cool. – AaronF Jun 15 '18 at 14:47
50

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.

Kevin Wright
  • 49,540
  • 9
  • 105
  • 155
  • 1
    In case anyone is reading this thread post 2021, Scala 3 infers the types correctly even if they are on a single parameter list. – ComDubh Oct 18 '21 at 12:42
30

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>
Tom Crockett
  • 30,818
  • 8
  • 72
  • 90
22

Back references in default arguments:

case class Foo(bar: Int)

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

test(Foo(3))()
0__
  • 66,707
  • 21
  • 171
  • 266
16

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.

psp
  • 12,138
  • 1
  • 41
  • 51
  • Interesting. Any chance you can expand on this? – Yuvi Masory Jan 14 '11 at 16:14
  • On case classes with multiple parameter lists, see [comments on this bug](https://issues.scala-lang.org/browse/SI-5009). That's where I heard about this feature first. – ebruchez Aug 16 '12 at 18:51