- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
{} vs. ()
Fri, 2009-07-17, 00:18
any succinct explanation of {} vs. () that would help me interpret +
generate correct Scala code more often than not? like, sometimes not
having ()s apparently means having to have {}s. perhaps besides the
language spec? or that, if need be. :-)
thanks.
Fri, 2009-07-17, 05:27
#2
Re: {} vs. ()
"When it comes to code, the parameters to a method call and the stuff
that follows "for" can use either () or {}."
Regarding the use of {} around parameters to a method call; you can only use this style when the method being called takes exactly 1 parameter. Therefore, given:
scala> def sum(i:Int, j:Int) = i+j
sum: (Int,Int)Int
You cannot use {} to pass parameters to this function; only parentheses are valid.
Daniel Sobral wrote:
Regarding the use of {} around parameters to a method call; you can only use this style when the method being called takes exactly 1 parameter. Therefore, given:
scala> def sum(i:Int, j:Int) = i+j
sum: (Int,Int)Int
You cannot use {} to pass parameters to this function; only parentheses are valid.
Daniel Sobral wrote:
6698c0870907162017u74fa8853hda207beaee037d7 [at] mail [dot] gmail [dot] com" type="cite">I was writing a blog about this, but the issue is more extensive than I had allowed time for.
I'll give the most important points, though.
Some things REQUIRE parenthesis. For instance, the keyword if and while must be followed by parenthesis and not curly braces. The keyword for, exceptionally, does not. The things which are not "code" generally require one or another (class declaration, package declaration, etc).
When it comes to code, the parameters to a method call and the stuff that follows "for" can use either () or {}.
Now, {} are used to delimit a block of statements, and () to delimit an expression, if you don't take it too strictly. But an expression is a statement, and a block of statements is an expression, so you can nest () and {} as you see fit.
Since () are used for tuple-literals, any commas inside it will make them into a tuple literal. {} can't be used for that. On the other hand, an expression does not contain statements, so ";" can't be used inside parenthesis -- with the exception of the parenthesis following a for statement.
Since () can't have statements, it doesn't have semi-colon inference either. That means an "(" will turn everything up to the closing ")" into a single expression, no matter how many lines it spans.
On the specific case of a for, you can use ";" to separate clauses inside parenthesis. As semi-colon inference does not exists for parenthesis, you must use them even with multiple lines. If you chose to use {}, though, the semi-colon inference on new-lines means you can do away with them.
Finally, a block of statements allows some stuff as the last statement -- the one that gives the block it's value -- that are not allowed on previous statements. I'll confess I do not recall right now what they are, but you can find it on the spec if you are really interested.
These are general rules to be guided by. They are not THE rules. :-)
On Thu, Jul 16, 2009 at 8:18 PM, Raoul Duke <raould [at] gmail [dot] com" rel="nofollow">raould@gmail.com> wrote:
any succinct explanation of {} vs. () that would help me interpret +
generate correct Scala code more often than not? like, sometimes not
having ()s apparently means having to have {}s. perhaps besides the
language spec? or that, if need be. :-)
thanks.
Fri, 2009-07-17, 23:57
#3
Re: {} vs. ()
On Fri, Jul 17, 2009 at 5:17 AM, Daniel Sobral wrote:
> I was writing a blog about this, but the issue is more extensive than I had
> allowed time for.
> I'll give the most important points, though.
...
These are all the rules in general that guard expressions or
statements involving braces or commas. But there's a simpler way to
state them, I think:
- Use (...) in statement forms where Java requires them.
- Argument lists and tuples are written in (...). We plan to unify
them at some point
in the future, but it's not done yet.
- A block is written inside { ... }. Blocks consist of statements that
are separated by `;' or new lines.
- A block can be passed as argument to a function without requiring an
extra set of (...).
- A for expression can use (...) (as in Java) or {...} because
generators in for expressions look
like statements.
To come back to the original question, () and {} are fully
interchangable. They both mean
the unit value.
> Finally, a block of statements allows some stuff as the last statement --
> the one that gives the block it's value -- that are not allowed on previous
> statements.
No, it's the other way round. A block may not END in a definition. The
last statement in a block must be an expression. (As far as I
remember, that's the same in Java).
Cheers
Sat, 2009-07-18, 06:57
#4
Re: {} vs. ()
> No, it's the other way round. A block may not END in a definition. The
> last statement in a block must be an expression. (As far as I
> remember, that's the same in Java).
It's not.
Mon, 2009-07-20, 09:57
#5
Re: {} vs. ()
Chris Lewis a écrit :
> "When it comes to code, the parameters to a method call and the stuff
> that follows "for" can use either () or {}."
>
> Regarding the use of {} around parameters to a method call; you can only
> use this style when the method being called takes exactly 1 parameter.
> Therefore, given:
>
> scala> def sum(i:Int, j:Int) = i+j
> sum: (Int,Int)Int
>
> You cannot use {} to pass parameters to this function; only parentheses
> are valid.
Well, you can not use {} where several parameters are needed. But look
at that:
scala> def sum2(i:Int)(j:Int) = sum(i,j)
sum2: (Int)(Int)Int
scala> sum2{1}{2}
res2: Int = 3
That works ;)
Mon, 2009-07-20, 13:57
#6
Re: {} vs. ()
Naturally, because that's two function invocations, each taking one
parameter :-)
fanf42@gmail.com wrote:
> Chris Lewis a écrit :
>> "When it comes to code, the parameters to a method call and the stuff
>> that follows "for" can use either () or {}."
>>
>> Regarding the use of {} around parameters to a method call; you can
>> only use this style when the method being called takes exactly 1
>> parameter. Therefore, given:
>>
>> scala> def sum(i:Int, j:Int) = i+j
>> sum: (Int,Int)Int
>>
>> You cannot use {} to pass parameters to this function; only
>> parentheses are valid.
>
>
> Well, you can not use {} where several parameters are needed. But look
> at that:
>
> scala> def sum2(i:Int)(j:Int) = sum(i,j)
> sum2: (Int)(Int)Int
>
> scala> sum2{1}{2}
> res2: Int = 3
>
> That works ;)
>
I'll give the most important points, though.
Some things REQUIRE parenthesis. For instance, the keyword if and while must be followed by parenthesis and not curly braces. The keyword for, exceptionally, does not. The things which are not "code" generally require one or another (class declaration, package declaration, etc).
When it comes to code, the parameters to a method call and the stuff that follows "for" can use either () or {}.
Now, {} are used to delimit a block of statements, and () to delimit an expression, if you don't take it too strictly. But an expression is a statement, and a block of statements is an expression, so you can nest () and {} as you see fit.
Since () are used for tuple-literals, any commas inside it will make them into a tuple literal. {} can't be used for that. On the other hand, an expression does not contain statements, so ";" can't be used inside parenthesis -- with the exception of the parenthesis following a for statement.
Since () can't have statements, it doesn't have semi-colon inference either. That means an "(" will turn everything up to the closing ")" into a single expression, no matter how many lines it spans.
On the specific case of a for, you can use ";" to separate clauses inside parenthesis. As semi-colon inference does not exists for parenthesis, you must use them even with multiple lines. If you chose to use {}, though, the semi-colon inference on new-lines means you can do away with them.
Finally, a block of statements allows some stuff as the last statement -- the one that gives the block it's value -- that are not allowed on previous statements. I'll confess I do not recall right now what they are, but you can find it on the spec if you are really interested.
These are general rules to be guided by. They are not THE rules. :-)
On Thu, Jul 16, 2009 at 8:18 PM, Raoul Duke <raould@gmail.com> wrote:
--
Daniel C. Sobral
Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.