Why can't a variable be assigned placeholder in function literal?

Question

I'm having trouble understanding underscores in function literals.

val l = List(1,2,3,4,5)
l.filter(_ > 0)

works fine

l.filter({_ > 0})

works fine

l.filter({val x=1; 1+_+3 > 0}) // ie you can have multiple statements in your function literal and use the underscore not just in the first statement.

works fine

And yet:

l.filter({val x=_; x > 0})
e>:1: error: unbound placeholder parameter
l.filter({val x=_; x > 0})

I can't assign the _ to a variable, even though the following is legal function literal:

l.filter(y => {val x=y; x > 0})

works fine.

What gives? Is my 'val x=_' getting interpreted as something else? Thanks!

Answer 1

Actually, you have to back up a step.

You are misunderstanding how the braces work.

scala> val is = (1 to 5).toList
is: List[Int] = List(1, 2, 3, 4, 5)

scala> is map ({ println("hi") ; 2 * _ })
hi
res2: List[Int] = List(2, 4, 6, 8, 10)

If the println were part of the function passed to map, you'd see more greetings.

scala> is map (i => { println("hi") ; 2 * i })
hi
hi
hi
hi
hi
res3: List[Int] = List(2, 4, 6, 8, 10)

Your extra braces are a block, which is some statements followed by a result expression. The result expr is the function.

Once you realize that only the result expr has an expected type that is the function expected by map, you wouldn't think to use underscore in the preceding statements, since a bare underscore needs the expected type to nail down what the underscore means.

That's the type system telling you that your underscore isn't in the right place.

Appendix: in comments you ask:

how can I use the underscore syntax to bind the parameter of a function literal to a variable

Is this a "dumb" question, pardon the expression?

The underscore is so you don't have to name the parameter, then you say you want to name it.

One use case might be: there are few incoming parameters, but I'm interested in naming only one of them.

scala> (0 /: is)(_ + _) res10: Int = 15

scala> (0 /: is) { case (acc, i) => acc + 2 * i } res11: Int = 30

This doesn't work, but one may wonder why. That is, we know what the fold expects, we want to apply something with an arg. Which arg? Whatever is left over after the partially applied partial function.

scala> (0 /: is) (({ case (_, i) => _ + 2 * i })(_))

or

scala> (0 /: is) (({ case (_, i) => val d = 2 * i; _ + 2 * d })(_))

SLS 6.23 "placeholder syntax for anonymous functions" mentions the "expr" boundary for when you must know what the underscore represents -- it's not a scope per se. If you supply type ascriptions for the underscores, it will still complain about the expected type, presumably because type inference goes left to right.

Answer 2

Because in this two cases underscore (_) means two different things. In case of a function it's a syntactic sugar for lambda function, your l.filter(_ > 0) later desugares into l.filter(x => x > 0). But in case of a var it has another meaning, not a lambda function, but a default value and this behavior is defined only for var's:

class Test {
  var num: Int = _
}

Here num gonna be initialized to its default value determined by its type Int. You can't do this with val cause vals are final and if in case of vars you can later assign them some different values, with vals this has no point.

Update

Consider this example:

l filter {
  val x = // compute something
  val z = _
  x == z
}

According to your idea, z should be bound to the first argument, but how scala should understand this, or you you have more code in this computation and then underscore.

Update 2

There is a grate option in scala repl: scala -Xprint:type. If you turn it on and print your code in (l.filter({val x=1; 1+_+3 > 0})), this what you'll see:

private[this] val res1: List[Int] = l.filter({
  val x: Int = 1;
  ((x$1: Int) => 1.+(x$1).+(3).>(0))
});

1+_+3 > 0 desugares into a function: ((x$1: Int) => 1.+(x$1).+(3).>(0)), what filter actually expects from you, a function from Int to Boolean. The following also works:

l.filter({val x=1; val f = 1+(_: Int)+3 > 0; f})

cause f here is a partially applied function from Int to Boolean, but underscore isn't assigned to the first argument, it's desugares to the closes scope:

private[this] val res3: List[Int] = l.filter({
  val x: Int = 1;
  val f: Int => Boolean = ((x$1: Int) => 1.+((x$1: Int)).+(3).>(0));
  f
});

Answer 3

The underscore syntax is mainly user for the following replacement:

coll.filter(x => { x % 2 == 0});
coll.filter(_ % 2 == 0);

This can only replace a single parameter. This is the placeholder syntax. Simple syntactic sugar for a lambda.

In the breaking case you are attempting null initialization/defaulting.

For primitive types with init conventions:

var x: Int = _; // x will be 0

The general case:

var y: List[String] = _; // y is null
var z: Any = _; // z = null;

To get pedantic, it works because null is a ref to the only instance of scala.Null, a sub-type of any type, which will always satisfy the type bound because of covariance. Look HERE.

A very common usage scenario, in ScalaTest:

class myTest extends FeatureTest with GivenWhenThen with BeforeAndAfter {
    var x: OAuthToken = _;
   before {
      x = someFunctionThatReturnsAToken;
   }
}

You can also see why you shouldn't use it with val, since the whole point is to update the value after initialization.

The compiler won't even let you, failing with: error: unbound placeholder parameter. This is your exact case, the compiler thinks you are defaulting, a behaviour undefined for vals.

Various constraints, such as timing or scope make this useful. This is different from lazy, where you predefine the expression that will be evaluated when needed.

For more usages of _ in Scala, look HERE.