Question: ```
scala> def a(i:Int)(j:Int) = i * j
a: (i: Int)(j: Int)Int

scala> def b(i:Int, j:Int) = i * j
b: (i: Int, j: Int)Int

```

The two definitions are very similar, and they (appear to me) do the same thing.

Apart from defining a function which receives implicit parameters or a code block as parameter, is there any reason to use the first definition style?

Answer: 
This is the list I have compiled over the time:

1) **Type resolution** across multiple argument lists

```scala
class ResourceManager {
  type Resource

  def open: Resource = ???
}

class ResourceManagerTest {
  // Does not compile: def test1(rm: ResourceManager, r: rm.Resource) = ???

  // Compiles: This way the type can be resolved
  def test2(rm: ResourceManager)(r: rm.Resource) = ???
}

```

2) **Type inference** where earlier arguments can "lock down" type parameters for later arguments (thanks to Myserious Dan)

```scala
  def foo1[A](x: A, f: A => Int) = ???

  def foo2[A](x: A)(f: A => Int) = ???

  def foo1foo2Demo() {
    // This will always demand a type annotation on any anonymous function
    // you pass in:
    foo1(1, (i: Int) => i * i)

    // Does not compile: foo1(1, i => i * i)

    // Type not required
    foo2(2)(i => i * i)
  }

```

3) **Syntax-like language extensions**

```scala
object MultipleArgumentListsDemo {
  // This style of function definition allows syntax-like language extensions
  @tailrec
  def myWhile(conditional: => Boolean)(f: => Unit) {
    if (conditional) {
      f
      myWhile(conditional)(f)
    }
  }

  def myWhileDemo() {
    var count = 0
    myWhile(count < 5) {
      count += 1
      println(count)
    }
  }

```

4) Having both **implicit and non implicit arguments**, as implicit is a modifier for a whole argument list:

```scala
  def f[A](x: A)(implicit mf: Manifest[A]) {
  }

```

5) A parameter's value from one parameter list can be used to compute a **default value** in another parameter list, but not in the same one.

```scala
  def g(x: Int)(y: Int = x * 2) = {
    x + y
  }

```

6) **Multiple repeated argument lists** ("varargs")

```scala
  def h(as: Int*)(bs: Int*)(cs: Int*) = as.sum * bs.sum * cs.sum

```

7) **Partial application**

```scala
  def i() {
    val foop = h(1, 2, 3)(4, 5, 6, 7, 9) _
    println(foop(Seq(10, 11)))
 }

```

As I have not tracked my sources while I was compiling that list over the time: It's possible that some or all examples are copied from elsewhere (other questions on SO), so please drop a note, and I will add the reference as to where it came from.
Additional to support currying, it also helps with type inference: Sometimes the compiler can't infer the correct type if everything is in one argument list, but if you split off the part that depends on the binding of the other arguments, it works. A typical example is `foldLeft`: Try to implement it with one argument list, and then in some cases the compiler needs type annotations.