When do I have to treat my methods as partially applied functions in Scala?

Question

I noticed that when I'm working with functions that expect other functions as parameters, I can sometimes do this:

someFunction(firstParam,anotherFunction)

But other times, the compiler is giving me an error, telling me that I should write a function like this, in order for it to treat it as a partially applied function:

someFunction(firstParam,anotherFunction _)

For example, if I have this:

object Whatever {
    def meth1(params:Array[Int]) = ...
    def meth2(params:Array[Int]) = ...
}

import Whatever._
val callbacks = Array(meth1 _,meth2 _)

Why can't I have the code like the following:

val callbacks = Array(meth1,meth2)

Under what circumstances will the compiler tell me to add _?

score 28 · Accepted Answer · answered Jul 11 '11 at 13:50

The rule is actually simple: you have to write the _ whenever the compiler is not explicitly expecting a Function object.

Example in the REPL:

scala> def f(i: Int) = i    
f: (i: Int)Int

scala> val g = f
<console>:6: error: missing arguments for method f in object $iw;
follow this method with `_' if you want to treat it as a partially applied function
       val g = f
               ^

scala> val g: Int => Int = f  
g: (Int) => Int = <function1>

score 6 · Answer 2 · answered Jul 11 '11 at 15:00

In Scala a method is not a function. The compiler can convert a method implicitly in a function, but it need to know which kind. So either you use the _ to convert it explicitly or you can give some indications about which function type to use:

object Whatever {
  def meth1(params:Array[Int]): Int = ...
  def meth2(params:Array[Int]): Int = ...
}

import Whatever._
val callbacks = Array[ Array[Int] => Int ]( meth1, meth2 )

or:

val callbacks: Array[ Array[Int] => Int ] = Array( meth1, meth2 )

See also [Myth: methods and functions are the same thing](http://stackoverflow.com/questions/3926047/debunking-scala-myths/4812176#4812176). — Aaron Novstrup, Jul 11 '11 at 18:47

agilesteel · Answer 3 · 2011-07-12T08:39:06.597

4

In addition to what Jean-Philippe Pellet said, you can use partially applied functions, when writing delegate classes:

class ThirdPartyAPI{
   def f(a: Int, b: String, c: Int) = ...
   // lots of other methods
}

// You want to hide all the unnecessary methods
class APIWrapper(r: ThirdPartyAPI) {
   // instead of writing this
   def f(a: Int, b: String, c: Int) = r.f(a, b, c)
   // you can write this
   def f(a: Int, b: String, c: Int) = r.f _
   // or even this
   def f = r.f _
}

EDIT added the def f = r.f _ part.

edited Jul 12 '11 at 08:39

answered Jul 11 '11 at 14:15

agilesteel

16,775
6
44
55

4

Note that it's not a *partial function*, it's a *partially applied function*. – Jean-Philippe Pellet Jul 11 '11 at 14:25
1

Shouldn't (r: RichAPI) be (r: ThnirdPartyAPI)? – user unknown Jul 11 '11 at 15:40
shouldn't the "//you can write this part" be: def f = r.f _ ? that creates f: (a: Int,b: String,c: Int)(Int, String, Int) => ... – JaimeJorge Jul 12 '11 at 03:10
I thought it's only possible with a function, but not a method. Nice to know, thx. I'll add it right away – agilesteel Jul 12 '11 at 08:36
@JaimeJorge @agilesteel the case `def f = r.f _` is different. `f` now becomes a method without a parameter list which returns a function of type `(Int, String, Int) => A`. There is some overhead here. – Jean-Philippe Pellet Jul 13 '11 at 09:00
@jean-philippe-pellet true, thanks. but the interface for the client is the same (and also reduces the number of keystrokes required). – JaimeJorge Jul 14 '11 at 03:37
The interface is not exactly the same — e.g., the client cannot use named parameters any more (or not the ones you'd think). – Jean-Philippe Pellet Jul 14 '11 at 06:44

When do I have to treat my methods as partially applied functions in Scala?

3 Answers3

Linked