Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When does Scala need parameter types for anonymous and expanded functions?

When does the Scala compiler really need the type information of parameters of anonymous functions?

For instance, given this function:

def callOn[T,R](target: T, f: (T => R)) = f(target)

then I cannot use it like this:

callOn(4, _.toString)
  => error: missing parameter type for expanded function ((x$1) => x$1.toString)

and I have to specify

callOn(4, (_: Int).toString)

which is rather ugly. Why doesn't my example work, whereas method like map, filter, foldLeft, etc. on the collection classes don't seem to need this explicit type?

like image 252
Jean-Philippe Pellet Avatar asked Feb 04 '11 14:02

Jean-Philippe Pellet


2 Answers

The trick to type inference is to consider it as an process of iterative refinement. Each parameter block can be used to infer some of the type parameters, which can then be used in subsequent blocks. So take the following definition:

def chain[T,A,B](x: T)(fn1: T=>A)(fn2: A=>B) = fn2(fn1(x))

called as:

chain(2)(_*10)("xxx"+_)

So how is this inferred? First, we start with the block (2) which is known to have the type Int. Substituting that back into the T parameter we get:

def chain[A,B](x: Int)(fn1: Int=>A)(fn2: A=>B) = fn2(fn1(x))

The next parameter block is (_*10), where we now know the type of the placeholder _ to be Int... and multiplying an Int by an Int gives another Int. This is true of the returned type even if an overflow occurrs; at the extreme end it may throw an exception, but exceptions have the type Nothing which is a subclass of everything else in the type system, so we can still say Nothing is-an Int and the inferred type of Int is still valid.

With A inferred, the method becomes:

def chain[B](x: Int)(fn1: Int=>Int)(fn2: Int=>B) = fn2(fn1(x))

Leaving only B which can be inferred from ("xxx"+_). As String + Int is a String, the method is now:

def chain(x: Int)(fn1: Int=>Int)(fn2: Int=>String) = fn2(fn1(x))

As the return type of the method comes direct from fn2, that can also be explicitly shown for completeness:

def chain(x: Int)(fn1: Int=>Int)(fn2: Int=>String): String = fn2(fn1(x))

There you have it, all types safely resolved, and the method proven to be statically valid.


In your case, you need the type T to be inferred before it's possible to infer R from the type T=>R. To do this you must split out the parameters into two distinct blocks, writing the method in a curried form:

def callOn[T,R](target: T)(f: (T => R)) = f(target)
like image 108
Kevin Wright Avatar answered Nov 07 '22 05:11

Kevin Wright


This question has also been answered here:

Passing functions for all applicable types around

You expect, ... for Scala's compiler to take into account both parameters to twice to infer the correct types. Scala doesn't do that, though -- it only uses information from one parameter list to the next, but not from one parameter to the next. That mean the parameters f and a [WS: target and f in this case] are analyzed independently, without having the advantage of knowing what the other is.

Note that it does work with a curried version:

scala> def callOn[T,R](target: T)(f: (T => R)) = f(target)
callOn: [T,R](target: T)(f: (T) => R)R

scala> callOn(4)(_.toString)
res0: java.lang.String = 4

scala> 
like image 29
Wilfred Springer Avatar answered Nov 07 '22 07:11

Wilfred Springer