By Yuvi Masory

2011-01-13 19:12:43 8 Comments

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.


@0__ 2013-02-27 20:22:33

Back references in default arguments:

case class Foo(bar: Int)

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


@Tom Crockett 2011-01-13 21:36:01

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>

@psp 2011-01-14 05:36:25

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.

@Yuvi Masory 2011-01-14 16:14:45

Interesting. Any chance you can expand on this?

@zapadlo 2012-04-22 20:44:49

Looks like no chance...

@ebruchez 2012-08-16 18:51:23

On case classes with multiple parameter lists, see comments on this bug. That's where I heard about this feature first.

@Kevin Wright 2011-01-14 00:36:01

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)

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.

@Knut Arne Vedaa 2011-01-13 19:55:43

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

@Tom Crockett 2011-01-13 21:22:59

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).

@Knut Arne Vedaa 2011-01-14 09:25:17

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.

@Yuvi Masory 2011-01-14 16:14:18

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.

@Tom Crockett 2011-01-14 23:42:44

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) => ...

@Th 00 mÄ s 2014-12-08 13:02:39

It might not be obvious to everyone what your example shows. Maybe 2 setences of explaination would do wonders.

@shinzou 2017-11-07 12:00:59

What's the point? Optional arguments?

@AaronF 2018-06-15 14:47:15

Multiple varargs. Until now a pipe dream. So cool.

Related Questions

Sponsored Content

1 Answered Questions

3 Answered Questions

[SOLVED] Why such operator definition is possible in Scala?

  • 2016-10-14 19:39:59
  • Vagif Abilov
  • 183 View
  • 7 Score
  • 3 Answer
  • Tags:   scala f# overloading

1 Answered Questions

1 Answered Questions

Scala multiple parameter lists and partial binding

  • 2016-06-15 20:52:23
  • aaa90210
  • 165 View
  • 1 Score
  • 1 Answer
  • Tags:   scala

2 Answered Questions

[SOLVED] Benefits of currying in Scala

  • 2014-12-25 14:54:32
  • initmax
  • 1795 View
  • 5 Score
  • 2 Answer
  • Tags:   scala

1 Answered Questions

1 Answered Questions

[SOLVED] What's the difference between currying and multiple parameter lists?

  • 2013-11-11 20:48:42
  • Matt Malone
  • 1045 View
  • 17 Score
  • 1 Answer
  • Tags:   scala currying

4 Answered Questions

2 Answered Questions

[SOLVED] Why does currying in Scala need multiple parameter lists?

  • 2012-09-30 11:22:08
  • Curious123
  • 618 View
  • 10 Score
  • 2 Answer
  • Tags:   scala

Sponsored Content