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         


        

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.