Constructing a lambda expression using an underscore

Constructing a lambda expression using an underscore - scala

This code
(1 to 30).foreach { x =>
println(x)
println
}
does what I'd expect: it prints each of 1 to 30, interspersed with blanks. I'm pretty clear on what's going on here, I think: I'm passing an anonymous function that first prints its argument, and then prints a blank line.
What I don't understand is why this doesn't do the same:
(1 to 30).foreach {
println _
println
}
It looks equivalent to me. The underscore should represent the first and only argument to the function; and the function prints its argument, and then prints a blank line. But when I run this second version, I don't get the blank lines.
What causes this difference?

The first variant is straightforward:
In the first line, apply println on x.
In the second line, apply the no-argument println (this prints the extra newline).
With the second variant you effectively tell Scala to do this:
In the first line, define a function object from println().
Subsequently, do nothing with this newly created object.
In the second line, apply println to the argument (the element of the
sequence).
The confusion stems from the assumption that println(x) and println _ are equivalent. They are different. The funcId _ syntax defines a new function based on funcId, it is not the same as using the "underscore argument" notation when calling a function.

There is a number of things going on here.
First, of all the parameter placeholder syntax can only be used within outer parentheses of the lambda definition. It cannot be used within parentheses of the method calls that you perform within the lambda definition.
Here is an example to demonstrate this point.
val a = (1 to 10).map(_ + 1)
This will work.
val b = (1 to 10).map(math.sin(_ + 1))
This will not work.
Therefore your code does not use parameter placeholder syntax at all. It instead uses partially applied functions.
For example
(1 to 10).foreach(println _)
is functionally equal to
val a = println (_ : Int)
(1 to 10).foreach(a)
Also when a method name is used within lambda expression the underscore can be omitted. Scala will still generate the partially applied method.
Therefore
(1 to 10).foreach(println)
is equal to
(1 to 10).foreach(println _)
And therefore your code is equal to
val a = println (_ : Int)
(1 to 10).foreach{
a
a
}
And because {a a} returns a, it is equal to
val a = println (_ : Int)
(1 to 10).foreach(a)

To add to other answers, there actually exists a way to use println(_) and not to declare x parameter:
(1 to 30).foreach {
println(_: Int)
println
}
Here foreach parameter is function, which firstly invokes println(_) for range element, and then passes println(Int) result (which is (): Unit) to another function, _ => println, which ignores it's argument and prints new line.

Related

() vs {} in foreach case [duplicate]

What is the formal difference between passing arguments to functions in parentheses () and in braces {}?
The feeling I got from the Programming in Scala book is that Scala's pretty flexible and I should use the one I like best, but I find that some cases compile while others don't.
For instance (just meant as an example; I would appreciate any response that discusses the general case, not this particular example only):
val tupleList = List[(String, String)]()
val filtered = tupleList.takeWhile( case (s1, s2) => s1 == s2 )
=> error: illegal start of simple expression
val filtered = tupleList.takeWhile{ case (s1, s2) => s1 == s2 }
=> fine.

I tried once to write about this, but I gave up in the end, as the rules are somewhat diffuse. Basically, you’ll have to get the hang of it.
Perhaps it is best to concentrate on where curly braces and parentheses can be used interchangeably: when passing parameters to method calls. You may replace curly braces with parentheses if, and only if, the method expects a single parameter. For example:
List(1, 2, 3).reduceLeft{_ + _} // valid, single Function2[Int,Int] parameter
List{1, 2, 3}.reduceLeft(_ + _) // invalid, A* vararg parameter
However, there’s more you need to know to better grasp these rules.
Increased compile checking with parens
The authors of Spray recommend round parens because they give increased compile checking. This is especially important for DSLs like Spray. By using parens you are telling the compiler that it should only be given a single line; therefore if you accidentally give it two or more, it will complain. Now this isn’t the case with curly braces – if for example you forget an operator somewhere, then your code will compile, and you get unexpected results and potentially a very hard bug to find. Below is contrived (since the expressions are pure and will at least give a warning), but makes the point:
method {
1 +
2
3
}
method(
1 +
2
3
)
The first compiles, the second gives error: ')' expected but integer literal found. The author wanted to write 1 + 2 + 3.
One could argue it’s similar for multi-parameter methods with default arguments; it’s impossible to accidentally forget a comma to separate parameters when using parens.
Verbosity
An important often overlooked note about verbosity. Using curly braces inevitably leads to verbose code since the Scala style guide clearly states that closing curly braces must be on their own line:
… the closing brace is on its own line immediately following the last
line of the function.
Many auto-reformatters, like in IntelliJ, will automatically perform this reformatting for you. So try to stick to using round parens when you can.
Infix Notation
When using infix notation, like List(1,2,3) indexOf (2) you can omit parentheses if there is only one parameter and write it as List(1, 2, 3) indexOf 2. This is not the case of dot-notation.
Note also that when you have a single parameter that is a multi-token expression, like x + 2 or a => a % 2 == 0, you have to use parentheses to indicate the boundaries of the expression.
Tuples
Because you can omit parentheses sometimes, sometimes a tuple needs extra parentheses like in ((1, 2)), and sometimes the outer parentheses can be omitted, like in (1, 2). This may cause confusion.
Function/Partial Function literals with case
Scala has a syntax for function and partial function literals. It looks like this:
{
case pattern if guard => statements
case pattern => statements
}
The only other places where you can use case statements are with the match and catch keywords:
object match {
case pattern if guard => statements
case pattern => statements
}
try {
block
} catch {
case pattern if guard => statements
case pattern => statements
} finally {
block
}
You cannot use case statements in any other context. So, if you want to use case, you need curly braces. In case you are wondering what makes the distinction between a function and partial function literal, the answer is: context. If Scala expects a function, a function you get. If it expects a partial function, you get a partial function. If both are expected, it gives an error about ambiguity.
Expressions and Blocks
Parentheses can be used to make subexpressions. Curly braces can be used to make blocks of code (this is not a function literal, so beware of trying to use it like one). A block of code consists of multiple statements, each of which can be an import statement, a declaration or an expression. It goes like this:
{
import stuff._
statement ; // ; optional at the end of the line
statement ; statement // not optional here
var x = 0 // declaration
while (x < 10) { x += 1 } // stuff
(x % 5) + 1 // expression
}
( expression )
So, if you need declarations, multiple statements, an import or anything like that, you need curly braces. And because an expression is a statement, parentheses may appear inside curly braces. But the interesting thing is that blocks of code are also expressions, so you can use them anywhere inside an expression:
( { var x = 0; while (x < 10) { x += 1}; x } % 5) + 1
So, since expressions are statements, and blocks of codes are expressions, everything below is valid:
1 // literal
(1) // expression
{1} // block of code
({1}) // expression with a block of code
{(1)} // block of code with an expression
({(1)}) // you get the drift...
Where they are not interchangeable
Basically, you can’t replace {} with () or vice versa anywhere else. For example:
while (x < 10) { x += 1 }
This is not a method call, so you can’t write it in any other way. Well, you can put curly braces inside the parentheses for the condition, as well as use parentheses inside the curly braces for the block of code:
while ({x < 10}) { (x += 1) }

There are a couple of different rules and inferences going on here: first of all, Scala infers the braces when a parameter is a function, e.g. in list.map(_ * 2) the braces are inferred, it's just a shorter form of list.map({_ * 2}). Secondly, Scala allows you to skip the parentheses on the last parameter list, if that parameter list has one parameter and it is a function, so list.foldLeft(0)(_ + _) can be written as list.foldLeft(0) { _ + _ } (or list.foldLeft(0)({_ + _}) if you want to be extra explicit).
However, if you add case you get, as others have mentioned, a partial function instead of a function, and Scala will not infer the braces for partial functions, so list.map(case x => x * 2) won't work, but both list.map({case x => 2 * 2}) and list.map { case x => x * 2 } will.

There is an effort from the community to standardize the usage of braces and parentheses, see Scala Style Guide (page 21): http://www.codecommit.com/scala-style-guide.pdf
The recommended syntax for higher order methods calls is to always use braces, and to skip the dot:
val filtered = tupleList takeWhile { case (s1, s2) => s1 == s2 }
For "normal" metod calls you should use the dot and parentheses.
val result = myInstance.foo(5, "Hello")

I don't think there is anything particular or complex about curly braces in Scala. To master the seeming-complex usage of them in Scala, just keep a couple of simple things in mind:
curly braces form a block of code, which evaluates to the last line of code (almost all languages do this)
a function if desired can be generated with the block of code (follows rule 1)
curly braces can be omitted for one-line code except for a case clause (Scala choice)
parentheses can be omitted in function call with code block as a parameter (Scala choice)
Let's explain a couple of examples per the above three rules:
val tupleList = List[(String, String)]()
// doesn't compile, violates case clause requirement
val filtered = tupleList.takeWhile( case (s1, s2) => s1 == s2 )
// block of code as a partial function and parentheses omission,
// i.e. tupleList.takeWhile({ case (s1, s2) => s1 == s2 })
val filtered = tupleList.takeWhile{ case (s1, s2) => s1 == s2 }
// curly braces omission, i.e. List(1, 2, 3).reduceLeft({_+_})
List(1, 2, 3).reduceLeft(_+_)
// parentheses omission, i.e. List(1, 2, 3).reduceLeft({_+_})
List(1, 2, 3).reduceLeft{_+_}
// not both though it compiles, because meaning totally changes due to precedence
List(1, 2, 3).reduceLeft _+_ // res1: String => String = <function1>
// curly braces omission, i.e. List(1, 2, 3).foldLeft(0)({_ + _})
List(1, 2, 3).foldLeft(0)(_ + _)
// parentheses omission, i.e. List(1, 2, 3).foldLeft(0)({_ + _})
List(1, 2, 3).foldLeft(0){_ + _}
// block of code and parentheses omission
List(1, 2, 3).foldLeft {0} {_ + _}
// not both though it compiles, because meaning totally changes due to precedence
List(1, 2, 3).foldLeft(0) _ + _
// error: ';' expected but integer literal found.
List(1, 2, 3).foldLeft 0 (_ + _)
def foo(f: Int => Unit) = { println("Entering foo"); f(4) }
// block of code that just evaluates to a value of a function, and parentheses omission
// i.e. foo({ println("Hey"); x => println(x) })
foo { println("Hey"); x => println(x) }
// parentheses omission, i.e. f({x})
def f(x: Int): Int = f {x}
// error: missing arguments for method f
def f(x: Int): Int = f x

I think it is worth explaining their usage in function calls and why various things happen. As someone already said curly braces define a block of code, which is also an expression so can be put where expression is expected and it will be evaluated. When evaluated, its statements are executed and last's statement value is the result of whole block evaluation (somewhat like in Ruby).
Having that we can do things like:
2 + { 3 } // res: Int = 5
val x = { 4 } // res: x: Int = 4
List({1},{2},{3}) // res: List[Int] = List(1,2,3)
Last example is just a function call with three parameters, of which each is evaluated first.
Now to see how it works with function calls let's define simple function that take another function as a parameter.
def foo(f: Int => Unit) = { println("Entering foo"); f(4) }
To call it, we need to pass function that takes one param of type Int, so we can use function literal and pass it to foo:
foo( x => println(x) )
Now as said before we can use block of code in place of an expression so let's use it
foo({ x => println(x) })
What happens here is that code inside {} is evaluated, and the function value is returned as a value of the block evaluation, this value is then passed to foo. This is semantically the same as previous call.
But we can add something more:
foo({ println("Hey"); x => println(x) })
Now our code block contains two statements, and because it is evaluated before foo is executed, what happens is that first "Hey" is printed, then our function is passed to foo, "Entering foo" is printed and lastly "4" is printed.
This looks a bit ugly though and Scala lets us to skip the parenthesis in this case, so we can write:
foo { println("Hey"); x => println(x) }
or
foo { x => println(x) }
That looks much nicer and is equivalent to the former ones. Here still block of code is evaluated first and the result of evaluation (which is x => println(x)) is passed as an argument to foo.

Because you are using case, you are defining a partial function and partial functions require curly braces.

Increased compile checking with parens
The authors of Spray, recommend that round parens give increased compile checking. This is especially important for DSLs like Spray. By using parens you are telling the compiler that it should only be given a single line, therefore if you accidentally gave it two or more, it will complain. Now this isn't the case with curly braces, if for example, you forget an operator somewhere your code will compile, you get unexpected results and potentially a very hard bug to find. Below is contrived (since the expressions are pure and will at least give a warning), but makes the point
method {
1 +
2
3
}
method(
1 +
2
3
)
The first compiles, the second gives error: ')' expected but integer literal found. the author wanted to write 1 + 2 + 3.
One could argue it's similar for multi-parameter methods with default arguments; it's impossible to accidentally forget a comma to separate parameters when using parens.
Verbosity
An important often overlooked note about verbosity. Using curly braces inevitably leads to verbose code since the scala style guide clearly states that closing curly braces must be on their own line: http://docs.scala-lang.org/style/declarations.html "... the closing brace is on its own line immediately following the last line of the function." Many auto-reformatters, like in Intellij, will automatically perform this reformatting for you. So try to stick to using round parens when you can. E.g. List(1, 2, 3).reduceLeft{_ + _} becomes:
List(1, 2, 3).reduceLeft {
_ + _
}

Parenthesis in an ideal coding style is basically used for single line code.
But if the particular piece of code is multiline then using braces is a better way.

With braces, you got semicolon induced for you and parentheses not. Consider takeWhile function, since it expects partial function, only {case xxx => ??? } is valid definition instead of parentheses around case expression.

Spark: Difference using map() and map{} [duplicate]

What is the formal difference between passing arguments to functions in parentheses () and in braces {}?
The feeling I got from the Programming in Scala book is that Scala's pretty flexible and I should use the one I like best, but I find that some cases compile while others don't.
For instance (just meant as an example; I would appreciate any response that discusses the general case, not this particular example only):
val tupleList = List[(String, String)]()
val filtered = tupleList.takeWhile( case (s1, s2) => s1 == s2 )
=> error: illegal start of simple expression
val filtered = tupleList.takeWhile{ case (s1, s2) => s1 == s2 }
=> fine.

I tried once to write about this, but I gave up in the end, as the rules are somewhat diffuse. Basically, you’ll have to get the hang of it.
Perhaps it is best to concentrate on where curly braces and parentheses can be used interchangeably: when passing parameters to method calls. You may replace curly braces with parentheses if, and only if, the method expects a single parameter. For example:
List(1, 2, 3).reduceLeft{_ + _} // valid, single Function2[Int,Int] parameter
List{1, 2, 3}.reduceLeft(_ + _) // invalid, A* vararg parameter
However, there’s more you need to know to better grasp these rules.
Increased compile checking with parens
The authors of Spray recommend round parens because they give increased compile checking. This is especially important for DSLs like Spray. By using parens you are telling the compiler that it should only be given a single line; therefore if you accidentally give it two or more, it will complain. Now this isn’t the case with curly braces – if for example you forget an operator somewhere, then your code will compile, and you get unexpected results and potentially a very hard bug to find. Below is contrived (since the expressions are pure and will at least give a warning), but makes the point:
method {
1 +
2
3
}
method(
1 +
2
3
)
The first compiles, the second gives error: ')' expected but integer literal found. The author wanted to write 1 + 2 + 3.
One could argue it’s similar for multi-parameter methods with default arguments; it’s impossible to accidentally forget a comma to separate parameters when using parens.
Verbosity
An important often overlooked note about verbosity. Using curly braces inevitably leads to verbose code since the Scala style guide clearly states that closing curly braces must be on their own line:
… the closing brace is on its own line immediately following the last
line of the function.
Many auto-reformatters, like in IntelliJ, will automatically perform this reformatting for you. So try to stick to using round parens when you can.
Infix Notation
When using infix notation, like List(1,2,3) indexOf (2) you can omit parentheses if there is only one parameter and write it as List(1, 2, 3) indexOf 2. This is not the case of dot-notation.
Note also that when you have a single parameter that is a multi-token expression, like x + 2 or a => a % 2 == 0, you have to use parentheses to indicate the boundaries of the expression.
Tuples
Because you can omit parentheses sometimes, sometimes a tuple needs extra parentheses like in ((1, 2)), and sometimes the outer parentheses can be omitted, like in (1, 2). This may cause confusion.
Function/Partial Function literals with case
Scala has a syntax for function and partial function literals. It looks like this:
{
case pattern if guard => statements
case pattern => statements
}
The only other places where you can use case statements are with the match and catch keywords:
object match {
case pattern if guard => statements
case pattern => statements
}
try {
block
} catch {
case pattern if guard => statements
case pattern => statements
} finally {
block
}
You cannot use case statements in any other context. So, if you want to use case, you need curly braces. In case you are wondering what makes the distinction between a function and partial function literal, the answer is: context. If Scala expects a function, a function you get. If it expects a partial function, you get a partial function. If both are expected, it gives an error about ambiguity.
Expressions and Blocks
Parentheses can be used to make subexpressions. Curly braces can be used to make blocks of code (this is not a function literal, so beware of trying to use it like one). A block of code consists of multiple statements, each of which can be an import statement, a declaration or an expression. It goes like this:
{
import stuff._
statement ; // ; optional at the end of the line
statement ; statement // not optional here
var x = 0 // declaration
while (x < 10) { x += 1 } // stuff
(x % 5) + 1 // expression
}
( expression )
So, if you need declarations, multiple statements, an import or anything like that, you need curly braces. And because an expression is a statement, parentheses may appear inside curly braces. But the interesting thing is that blocks of code are also expressions, so you can use them anywhere inside an expression:
( { var x = 0; while (x < 10) { x += 1}; x } % 5) + 1
So, since expressions are statements, and blocks of codes are expressions, everything below is valid:
1 // literal
(1) // expression
{1} // block of code
({1}) // expression with a block of code
{(1)} // block of code with an expression
({(1)}) // you get the drift...
Where they are not interchangeable
Basically, you can’t replace {} with () or vice versa anywhere else. For example:
while (x < 10) { x += 1 }
This is not a method call, so you can’t write it in any other way. Well, you can put curly braces inside the parentheses for the condition, as well as use parentheses inside the curly braces for the block of code:
while ({x < 10}) { (x += 1) }

There are a couple of different rules and inferences going on here: first of all, Scala infers the braces when a parameter is a function, e.g. in list.map(_ * 2) the braces are inferred, it's just a shorter form of list.map({_ * 2}). Secondly, Scala allows you to skip the parentheses on the last parameter list, if that parameter list has one parameter and it is a function, so list.foldLeft(0)(_ + _) can be written as list.foldLeft(0) { _ + _ } (or list.foldLeft(0)({_ + _}) if you want to be extra explicit).
However, if you add case you get, as others have mentioned, a partial function instead of a function, and Scala will not infer the braces for partial functions, so list.map(case x => x * 2) won't work, but both list.map({case x => 2 * 2}) and list.map { case x => x * 2 } will.

There is an effort from the community to standardize the usage of braces and parentheses, see Scala Style Guide (page 21): http://www.codecommit.com/scala-style-guide.pdf
The recommended syntax for higher order methods calls is to always use braces, and to skip the dot:
val filtered = tupleList takeWhile { case (s1, s2) => s1 == s2 }
For "normal" metod calls you should use the dot and parentheses.
val result = myInstance.foo(5, "Hello")

I don't think there is anything particular or complex about curly braces in Scala. To master the seeming-complex usage of them in Scala, just keep a couple of simple things in mind:
curly braces form a block of code, which evaluates to the last line of code (almost all languages do this)
a function if desired can be generated with the block of code (follows rule 1)
curly braces can be omitted for one-line code except for a case clause (Scala choice)
parentheses can be omitted in function call with code block as a parameter (Scala choice)
Let's explain a couple of examples per the above three rules:
val tupleList = List[(String, String)]()
// doesn't compile, violates case clause requirement
val filtered = tupleList.takeWhile( case (s1, s2) => s1 == s2 )
// block of code as a partial function and parentheses omission,
// i.e. tupleList.takeWhile({ case (s1, s2) => s1 == s2 })
val filtered = tupleList.takeWhile{ case (s1, s2) => s1 == s2 }
// curly braces omission, i.e. List(1, 2, 3).reduceLeft({_+_})
List(1, 2, 3).reduceLeft(_+_)
// parentheses omission, i.e. List(1, 2, 3).reduceLeft({_+_})
List(1, 2, 3).reduceLeft{_+_}
// not both though it compiles, because meaning totally changes due to precedence
List(1, 2, 3).reduceLeft _+_ // res1: String => String = <function1>
// curly braces omission, i.e. List(1, 2, 3).foldLeft(0)({_ + _})
List(1, 2, 3).foldLeft(0)(_ + _)
// parentheses omission, i.e. List(1, 2, 3).foldLeft(0)({_ + _})
List(1, 2, 3).foldLeft(0){_ + _}
// block of code and parentheses omission
List(1, 2, 3).foldLeft {0} {_ + _}
// not both though it compiles, because meaning totally changes due to precedence
List(1, 2, 3).foldLeft(0) _ + _
// error: ';' expected but integer literal found.
List(1, 2, 3).foldLeft 0 (_ + _)
def foo(f: Int => Unit) = { println("Entering foo"); f(4) }
// block of code that just evaluates to a value of a function, and parentheses omission
// i.e. foo({ println("Hey"); x => println(x) })
foo { println("Hey"); x => println(x) }
// parentheses omission, i.e. f({x})
def f(x: Int): Int = f {x}
// error: missing arguments for method f
def f(x: Int): Int = f x

I think it is worth explaining their usage in function calls and why various things happen. As someone already said curly braces define a block of code, which is also an expression so can be put where expression is expected and it will be evaluated. When evaluated, its statements are executed and last's statement value is the result of whole block evaluation (somewhat like in Ruby).
Having that we can do things like:
2 + { 3 } // res: Int = 5
val x = { 4 } // res: x: Int = 4
List({1},{2},{3}) // res: List[Int] = List(1,2,3)
Last example is just a function call with three parameters, of which each is evaluated first.
Now to see how it works with function calls let's define simple function that take another function as a parameter.
def foo(f: Int => Unit) = { println("Entering foo"); f(4) }
To call it, we need to pass function that takes one param of type Int, so we can use function literal and pass it to foo:
foo( x => println(x) )
Now as said before we can use block of code in place of an expression so let's use it
foo({ x => println(x) })
What happens here is that code inside {} is evaluated, and the function value is returned as a value of the block evaluation, this value is then passed to foo. This is semantically the same as previous call.
But we can add something more:
foo({ println("Hey"); x => println(x) })
Now our code block contains two statements, and because it is evaluated before foo is executed, what happens is that first "Hey" is printed, then our function is passed to foo, "Entering foo" is printed and lastly "4" is printed.
This looks a bit ugly though and Scala lets us to skip the parenthesis in this case, so we can write:
foo { println("Hey"); x => println(x) }
or
foo { x => println(x) }
That looks much nicer and is equivalent to the former ones. Here still block of code is evaluated first and the result of evaluation (which is x => println(x)) is passed as an argument to foo.

Because you are using case, you are defining a partial function and partial functions require curly braces.

Parenthesis in an ideal coding style is basically used for single line code.
But if the particular piece of code is multiline then using braces is a better way.

With braces, you got semicolon induced for you and parentheses not. Consider takeWhile function, since it expects partial function, only {case xxx => ??? } is valid definition instead of parentheses around case expression.

why does scala pattern match require curly bracket [duplicate]

What is the formal difference between passing arguments to functions in parentheses () and in braces {}?
The feeling I got from the Programming in Scala book is that Scala's pretty flexible and I should use the one I like best, but I find that some cases compile while others don't.
For instance (just meant as an example; I would appreciate any response that discusses the general case, not this particular example only):
val tupleList = List[(String, String)]()
val filtered = tupleList.takeWhile( case (s1, s2) => s1 == s2 )
=> error: illegal start of simple expression
val filtered = tupleList.takeWhile{ case (s1, s2) => s1 == s2 }
=> fine.

I tried once to write about this, but I gave up in the end, as the rules are somewhat diffuse. Basically, you’ll have to get the hang of it.
Perhaps it is best to concentrate on where curly braces and parentheses can be used interchangeably: when passing parameters to method calls. You may replace curly braces with parentheses if, and only if, the method expects a single parameter. For example:
List(1, 2, 3).reduceLeft{_ + _} // valid, single Function2[Int,Int] parameter
List{1, 2, 3}.reduceLeft(_ + _) // invalid, A* vararg parameter
However, there’s more you need to know to better grasp these rules.
Increased compile checking with parens
The authors of Spray recommend round parens because they give increased compile checking. This is especially important for DSLs like Spray. By using parens you are telling the compiler that it should only be given a single line; therefore if you accidentally give it two or more, it will complain. Now this isn’t the case with curly braces – if for example you forget an operator somewhere, then your code will compile, and you get unexpected results and potentially a very hard bug to find. Below is contrived (since the expressions are pure and will at least give a warning), but makes the point:
method {
1 +
2
3
}
method(
1 +
2
3
)
The first compiles, the second gives error: ')' expected but integer literal found. The author wanted to write 1 + 2 + 3.
One could argue it’s similar for multi-parameter methods with default arguments; it’s impossible to accidentally forget a comma to separate parameters when using parens.
Verbosity
An important often overlooked note about verbosity. Using curly braces inevitably leads to verbose code since the Scala style guide clearly states that closing curly braces must be on their own line:
… the closing brace is on its own line immediately following the last
line of the function.
Many auto-reformatters, like in IntelliJ, will automatically perform this reformatting for you. So try to stick to using round parens when you can.
Infix Notation
When using infix notation, like List(1,2,3) indexOf (2) you can omit parentheses if there is only one parameter and write it as List(1, 2, 3) indexOf 2. This is not the case of dot-notation.
Note also that when you have a single parameter that is a multi-token expression, like x + 2 or a => a % 2 == 0, you have to use parentheses to indicate the boundaries of the expression.
Tuples
Because you can omit parentheses sometimes, sometimes a tuple needs extra parentheses like in ((1, 2)), and sometimes the outer parentheses can be omitted, like in (1, 2). This may cause confusion.
Function/Partial Function literals with case
Scala has a syntax for function and partial function literals. It looks like this:
{
case pattern if guard => statements
case pattern => statements
}
The only other places where you can use case statements are with the match and catch keywords:
object match {
case pattern if guard => statements
case pattern => statements
}
try {
block
} catch {
case pattern if guard => statements
case pattern => statements
} finally {
block
}
You cannot use case statements in any other context. So, if you want to use case, you need curly braces. In case you are wondering what makes the distinction between a function and partial function literal, the answer is: context. If Scala expects a function, a function you get. If it expects a partial function, you get a partial function. If both are expected, it gives an error about ambiguity.
Expressions and Blocks
Parentheses can be used to make subexpressions. Curly braces can be used to make blocks of code (this is not a function literal, so beware of trying to use it like one). A block of code consists of multiple statements, each of which can be an import statement, a declaration or an expression. It goes like this:
{
import stuff._
statement ; // ; optional at the end of the line
statement ; statement // not optional here
var x = 0 // declaration
while (x < 10) { x += 1 } // stuff
(x % 5) + 1 // expression
}
( expression )
So, if you need declarations, multiple statements, an import or anything like that, you need curly braces. And because an expression is a statement, parentheses may appear inside curly braces. But the interesting thing is that blocks of code are also expressions, so you can use them anywhere inside an expression:
( { var x = 0; while (x < 10) { x += 1}; x } % 5) + 1
So, since expressions are statements, and blocks of codes are expressions, everything below is valid:
1 // literal
(1) // expression
{1} // block of code
({1}) // expression with a block of code
{(1)} // block of code with an expression
({(1)}) // you get the drift...
Where they are not interchangeable
Basically, you can’t replace {} with () or vice versa anywhere else. For example:
while (x < 10) { x += 1 }
This is not a method call, so you can’t write it in any other way. Well, you can put curly braces inside the parentheses for the condition, as well as use parentheses inside the curly braces for the block of code:
while ({x < 10}) { (x += 1) }

There are a couple of different rules and inferences going on here: first of all, Scala infers the braces when a parameter is a function, e.g. in list.map(_ * 2) the braces are inferred, it's just a shorter form of list.map({_ * 2}). Secondly, Scala allows you to skip the parentheses on the last parameter list, if that parameter list has one parameter and it is a function, so list.foldLeft(0)(_ + _) can be written as list.foldLeft(0) { _ + _ } (or list.foldLeft(0)({_ + _}) if you want to be extra explicit).
However, if you add case you get, as others have mentioned, a partial function instead of a function, and Scala will not infer the braces for partial functions, so list.map(case x => x * 2) won't work, but both list.map({case x => 2 * 2}) and list.map { case x => x * 2 } will.

There is an effort from the community to standardize the usage of braces and parentheses, see Scala Style Guide (page 21): http://www.codecommit.com/scala-style-guide.pdf
The recommended syntax for higher order methods calls is to always use braces, and to skip the dot:
val filtered = tupleList takeWhile { case (s1, s2) => s1 == s2 }
For "normal" metod calls you should use the dot and parentheses.
val result = myInstance.foo(5, "Hello")

I don't think there is anything particular or complex about curly braces in Scala. To master the seeming-complex usage of them in Scala, just keep a couple of simple things in mind:
curly braces form a block of code, which evaluates to the last line of code (almost all languages do this)
a function if desired can be generated with the block of code (follows rule 1)
curly braces can be omitted for one-line code except for a case clause (Scala choice)
parentheses can be omitted in function call with code block as a parameter (Scala choice)
Let's explain a couple of examples per the above three rules:
val tupleList = List[(String, String)]()
// doesn't compile, violates case clause requirement
val filtered = tupleList.takeWhile( case (s1, s2) => s1 == s2 )
// block of code as a partial function and parentheses omission,
// i.e. tupleList.takeWhile({ case (s1, s2) => s1 == s2 })
val filtered = tupleList.takeWhile{ case (s1, s2) => s1 == s2 }
// curly braces omission, i.e. List(1, 2, 3).reduceLeft({_+_})
List(1, 2, 3).reduceLeft(_+_)
// parentheses omission, i.e. List(1, 2, 3).reduceLeft({_+_})
List(1, 2, 3).reduceLeft{_+_}
// not both though it compiles, because meaning totally changes due to precedence
List(1, 2, 3).reduceLeft _+_ // res1: String => String = <function1>
// curly braces omission, i.e. List(1, 2, 3).foldLeft(0)({_ + _})
List(1, 2, 3).foldLeft(0)(_ + _)
// parentheses omission, i.e. List(1, 2, 3).foldLeft(0)({_ + _})
List(1, 2, 3).foldLeft(0){_ + _}
// block of code and parentheses omission
List(1, 2, 3).foldLeft {0} {_ + _}
// not both though it compiles, because meaning totally changes due to precedence
List(1, 2, 3).foldLeft(0) _ + _
// error: ';' expected but integer literal found.
List(1, 2, 3).foldLeft 0 (_ + _)
def foo(f: Int => Unit) = { println("Entering foo"); f(4) }
// block of code that just evaluates to a value of a function, and parentheses omission
// i.e. foo({ println("Hey"); x => println(x) })
foo { println("Hey"); x => println(x) }
// parentheses omission, i.e. f({x})
def f(x: Int): Int = f {x}
// error: missing arguments for method f
def f(x: Int): Int = f x

I think it is worth explaining their usage in function calls and why various things happen. As someone already said curly braces define a block of code, which is also an expression so can be put where expression is expected and it will be evaluated. When evaluated, its statements are executed and last's statement value is the result of whole block evaluation (somewhat like in Ruby).
Having that we can do things like:
2 + { 3 } // res: Int = 5
val x = { 4 } // res: x: Int = 4
List({1},{2},{3}) // res: List[Int] = List(1,2,3)
Last example is just a function call with three parameters, of which each is evaluated first.
Now to see how it works with function calls let's define simple function that take another function as a parameter.
def foo(f: Int => Unit) = { println("Entering foo"); f(4) }
To call it, we need to pass function that takes one param of type Int, so we can use function literal and pass it to foo:
foo( x => println(x) )
Now as said before we can use block of code in place of an expression so let's use it
foo({ x => println(x) })
What happens here is that code inside {} is evaluated, and the function value is returned as a value of the block evaluation, this value is then passed to foo. This is semantically the same as previous call.
But we can add something more:
foo({ println("Hey"); x => println(x) })
Now our code block contains two statements, and because it is evaluated before foo is executed, what happens is that first "Hey" is printed, then our function is passed to foo, "Entering foo" is printed and lastly "4" is printed.
This looks a bit ugly though and Scala lets us to skip the parenthesis in this case, so we can write:
foo { println("Hey"); x => println(x) }
or
foo { x => println(x) }
That looks much nicer and is equivalent to the former ones. Here still block of code is evaluated first and the result of evaluation (which is x => println(x)) is passed as an argument to foo.

Because you are using case, you are defining a partial function and partial functions require curly braces.

Parenthesis in an ideal coding style is basically used for single line code.
But if the particular piece of code is multiline then using braces is a better way.

With braces, you got semicolon induced for you and parentheses not. Consider takeWhile function, since it expects partial function, only {case xxx => ??? } is valid definition instead of parentheses around case expression.

Getting an error while passing an expression as a fucntion parameter

scala> def sum(a:Int)={a} //I have defined the function with a single parameter
sum: (a: Int)Int
sum{val b=10+20} //passing the parameter as expression block
Getting error
scala> sum{val b=10+20}
<console>:9: error: type mismatch;
found : Unit
required: Int
sum{val b=10+20}
Why is it expecting Unit here?

The error is that {val b = 10 + 20} is of type Unit while sum is expecting an Int.
You can either call sum directly without assigning the variable:
sum(10 + 20)
> 30
Or make the block return an Int, like:
sum{
val b = 10 + 20
b // return b, which is an Int
}
> 30

You do not pass an expression but a block with one declaration. Try:
sum(10+20)
You are experiencing a weird combination of syntax error and type-system convention.
The curly braces mark a block (see e.g. the body of your sum function declaration). Function arguments can be passed in juxtaposition or using parenthesis. That is your syntax error.
The type system convention allows languages with side-effects to gently insert these effects into basically any expression. This happens by treating the composition of statements (i.e. the semicolon) as "evaluate these expression but do nothing with the result, then evaluate the next expression". The nothing as result part is combined with the unit type for statements that do not compute anything.

def sum(a:Int)={a}
What this statement does is create a method that takes one Int-typed parameter and returns it.
sum{val b=10+20}
Here you pass a value to your defined method sum. What you're passing is an expression. Scala will, effectively, 'rewrite' that expression before applying it to sum. If we write the expression being passed (val b=10+20) in the REPL we will see what it gets rewritten to:
scala> val b=10+20
b: Int = 30
But this is only part of the story, because the assignment of a value to a name returns nothing. We can see this by putting brackets around the assignment:
scala> { val b=10+20 }
Note that the REPL displays nothing when this happens.
Because the re-written expression includes this evaluation, you're actually passing a scope to the function, in which b is defined. However, that scope doesn't 'return' an Int to be bound to a. To return the result of the b assignment, you have to do one of two things. Either you have to have a call to the variable be the last call in the expression, or have the last call be the calculation itself, and don't assign that to a variable:
sum{ val b=10+20; b } // Explicitly call the bound variable
sum{ 10 + 20 } // Don't assign the variable

What is the formal difference in Scala between braces and parentheses, and when should they be used?

What is the formal difference between passing arguments to functions in parentheses () and in braces {}?
The feeling I got from the Programming in Scala book is that Scala's pretty flexible and I should use the one I like best, but I find that some cases compile while others don't.
For instance (just meant as an example; I would appreciate any response that discusses the general case, not this particular example only):
val tupleList = List[(String, String)]()
val filtered = tupleList.takeWhile( case (s1, s2) => s1 == s2 )
=> error: illegal start of simple expression
val filtered = tupleList.takeWhile{ case (s1, s2) => s1 == s2 }
=> fine.

I tried once to write about this, but I gave up in the end, as the rules are somewhat diffuse. Basically, you’ll have to get the hang of it.
Perhaps it is best to concentrate on where curly braces and parentheses can be used interchangeably: when passing parameters to method calls. You may replace curly braces with parentheses if, and only if, the method expects a single parameter. For example:
List(1, 2, 3).reduceLeft{_ + _} // valid, single Function2[Int,Int] parameter
List{1, 2, 3}.reduceLeft(_ + _) // invalid, A* vararg parameter
However, there’s more you need to know to better grasp these rules.
Increased compile checking with parens
The authors of Spray recommend round parens because they give increased compile checking. This is especially important for DSLs like Spray. By using parens you are telling the compiler that it should only be given a single line; therefore if you accidentally give it two or more, it will complain. Now this isn’t the case with curly braces – if for example you forget an operator somewhere, then your code will compile, and you get unexpected results and potentially a very hard bug to find. Below is contrived (since the expressions are pure and will at least give a warning), but makes the point:
method {
1 +
2
3
}
method(
1 +
2
3
)
The first compiles, the second gives error: ')' expected but integer literal found. The author wanted to write 1 + 2 + 3.
One could argue it’s similar for multi-parameter methods with default arguments; it’s impossible to accidentally forget a comma to separate parameters when using parens.
Verbosity
An important often overlooked note about verbosity. Using curly braces inevitably leads to verbose code since the Scala style guide clearly states that closing curly braces must be on their own line:
… the closing brace is on its own line immediately following the last
line of the function.
Many auto-reformatters, like in IntelliJ, will automatically perform this reformatting for you. So try to stick to using round parens when you can.
Infix Notation
When using infix notation, like List(1,2,3) indexOf (2) you can omit parentheses if there is only one parameter and write it as List(1, 2, 3) indexOf 2. This is not the case of dot-notation.
Note also that when you have a single parameter that is a multi-token expression, like x + 2 or a => a % 2 == 0, you have to use parentheses to indicate the boundaries of the expression.
Tuples
Because you can omit parentheses sometimes, sometimes a tuple needs extra parentheses like in ((1, 2)), and sometimes the outer parentheses can be omitted, like in (1, 2). This may cause confusion.
Function/Partial Function literals with case
Scala has a syntax for function and partial function literals. It looks like this:
{
case pattern if guard => statements
case pattern => statements
}
The only other places where you can use case statements are with the match and catch keywords:
object match {
case pattern if guard => statements
case pattern => statements
}
try {
block
} catch {
case pattern if guard => statements
case pattern => statements
} finally {
block
}
You cannot use case statements in any other context. So, if you want to use case, you need curly braces. In case you are wondering what makes the distinction between a function and partial function literal, the answer is: context. If Scala expects a function, a function you get. If it expects a partial function, you get a partial function. If both are expected, it gives an error about ambiguity.
Expressions and Blocks
Parentheses can be used to make subexpressions. Curly braces can be used to make blocks of code (this is not a function literal, so beware of trying to use it like one). A block of code consists of multiple statements, each of which can be an import statement, a declaration or an expression. It goes like this:
{
import stuff._
statement ; // ; optional at the end of the line
statement ; statement // not optional here
var x = 0 // declaration
while (x < 10) { x += 1 } // stuff
(x % 5) + 1 // expression
}
( expression )
So, if you need declarations, multiple statements, an import or anything like that, you need curly braces. And because an expression is a statement, parentheses may appear inside curly braces. But the interesting thing is that blocks of code are also expressions, so you can use them anywhere inside an expression:
( { var x = 0; while (x < 10) { x += 1}; x } % 5) + 1
So, since expressions are statements, and blocks of codes are expressions, everything below is valid:
1 // literal
(1) // expression
{1} // block of code
({1}) // expression with a block of code
{(1)} // block of code with an expression
({(1)}) // you get the drift...
Where they are not interchangeable
Basically, you can’t replace {} with () or vice versa anywhere else. For example:
while (x < 10) { x += 1 }
This is not a method call, so you can’t write it in any other way. Well, you can put curly braces inside the parentheses for the condition, as well as use parentheses inside the curly braces for the block of code:
while ({x < 10}) { (x += 1) }

There are a couple of different rules and inferences going on here: first of all, Scala infers the braces when a parameter is a function, e.g. in list.map(_ * 2) the braces are inferred, it's just a shorter form of list.map({_ * 2}). Secondly, Scala allows you to skip the parentheses on the last parameter list, if that parameter list has one parameter and it is a function, so list.foldLeft(0)(_ + _) can be written as list.foldLeft(0) { _ + _ } (or list.foldLeft(0)({_ + _}) if you want to be extra explicit).
However, if you add case you get, as others have mentioned, a partial function instead of a function, and Scala will not infer the braces for partial functions, so list.map(case x => x * 2) won't work, but both list.map({case x => 2 * 2}) and list.map { case x => x * 2 } will.

There is an effort from the community to standardize the usage of braces and parentheses, see Scala Style Guide (page 21): http://www.codecommit.com/scala-style-guide.pdf
The recommended syntax for higher order methods calls is to always use braces, and to skip the dot:
val filtered = tupleList takeWhile { case (s1, s2) => s1 == s2 }
For "normal" metod calls you should use the dot and parentheses.
val result = myInstance.foo(5, "Hello")

I don't think there is anything particular or complex about curly braces in Scala. To master the seeming-complex usage of them in Scala, just keep a couple of simple things in mind:
curly braces form a block of code, which evaluates to the last line of code (almost all languages do this)
a function if desired can be generated with the block of code (follows rule 1)
curly braces can be omitted for one-line code except for a case clause (Scala choice)
parentheses can be omitted in function call with code block as a parameter (Scala choice)
Let's explain a couple of examples per the above three rules:
val tupleList = List[(String, String)]()
// doesn't compile, violates case clause requirement
val filtered = tupleList.takeWhile( case (s1, s2) => s1 == s2 )
// block of code as a partial function and parentheses omission,
// i.e. tupleList.takeWhile({ case (s1, s2) => s1 == s2 })
val filtered = tupleList.takeWhile{ case (s1, s2) => s1 == s2 }
// curly braces omission, i.e. List(1, 2, 3).reduceLeft({_+_})
List(1, 2, 3).reduceLeft(_+_)
// parentheses omission, i.e. List(1, 2, 3).reduceLeft({_+_})
List(1, 2, 3).reduceLeft{_+_}
// not both though it compiles, because meaning totally changes due to precedence
List(1, 2, 3).reduceLeft _+_ // res1: String => String = <function1>
// curly braces omission, i.e. List(1, 2, 3).foldLeft(0)({_ + _})
List(1, 2, 3).foldLeft(0)(_ + _)
// parentheses omission, i.e. List(1, 2, 3).foldLeft(0)({_ + _})
List(1, 2, 3).foldLeft(0){_ + _}
// block of code and parentheses omission
List(1, 2, 3).foldLeft {0} {_ + _}
// not both though it compiles, because meaning totally changes due to precedence
List(1, 2, 3).foldLeft(0) _ + _
// error: ';' expected but integer literal found.
List(1, 2, 3).foldLeft 0 (_ + _)
def foo(f: Int => Unit) = { println("Entering foo"); f(4) }
// block of code that just evaluates to a value of a function, and parentheses omission
// i.e. foo({ println("Hey"); x => println(x) })
foo { println("Hey"); x => println(x) }
// parentheses omission, i.e. f({x})
def f(x: Int): Int = f {x}
// error: missing arguments for method f
def f(x: Int): Int = f x

I think it is worth explaining their usage in function calls and why various things happen. As someone already said curly braces define a block of code, which is also an expression so can be put where expression is expected and it will be evaluated. When evaluated, its statements are executed and last's statement value is the result of whole block evaluation (somewhat like in Ruby).
Having that we can do things like:
2 + { 3 } // res: Int = 5
val x = { 4 } // res: x: Int = 4
List({1},{2},{3}) // res: List[Int] = List(1,2,3)
Last example is just a function call with three parameters, of which each is evaluated first.
Now to see how it works with function calls let's define simple function that take another function as a parameter.
def foo(f: Int => Unit) = { println("Entering foo"); f(4) }
To call it, we need to pass function that takes one param of type Int, so we can use function literal and pass it to foo:
foo( x => println(x) )
Now as said before we can use block of code in place of an expression so let's use it
foo({ x => println(x) })
What happens here is that code inside {} is evaluated, and the function value is returned as a value of the block evaluation, this value is then passed to foo. This is semantically the same as previous call.
But we can add something more:
foo({ println("Hey"); x => println(x) })
Now our code block contains two statements, and because it is evaluated before foo is executed, what happens is that first "Hey" is printed, then our function is passed to foo, "Entering foo" is printed and lastly "4" is printed.
This looks a bit ugly though and Scala lets us to skip the parenthesis in this case, so we can write:
foo { println("Hey"); x => println(x) }
or
foo { x => println(x) }
That looks much nicer and is equivalent to the former ones. Here still block of code is evaluated first and the result of evaluation (which is x => println(x)) is passed as an argument to foo.

Because you are using case, you are defining a partial function and partial functions require curly braces.

Parenthesis in an ideal coding style is basically used for single line code.
But if the particular piece of code is multiline then using braces is a better way.

With braces, you got semicolon induced for you and parentheses not. Consider takeWhile function, since it expects partial function, only {case xxx => ??? } is valid definition instead of parentheses around case expression.

We Keep Coding

iphone swift flutter scala powershell matlab mongodb postgresql perl eclipse