What do parentheses and curly brackets mean?

On Mon, Jul 11, 2011 at 18:50, Eike Welk wrote:
> Curly brackets seem to have a different meaning in Scala than in C++. (I don't
> know Java.) In several situations one can use them interchangeably with
> parentheses.

To put it simply, The use of {} -- with a couple of exceptions --
indicates a block of code, which is composed of multiple statements
and declarations, and whose value is that of the last statement. As
far as I can remember, and seems confirmed by a brief test, that is no
different than in C, though I can hardly recall seeing them used like
this.

They can be used instead of () as delimiter for parameter lists of
arity 1 (ie, one argument).

> Can someone explain to me the meaning of parentheses and curly brackets in
> these examples?
>
>    def foo(x:Int) (y:Int) = x + y
>    val i1 = foo(1) (2)
>    val i2 = foo{1} {2}

Both parameter lists of foo have a single argument, so {} can be used
instead of ().

>
>    val f1 = (_.toDouble): (Int)=>Double
>    val f2 = {_.toDouble}: (Int)=>Double

This is no different than a plain expression. Consider this:

val f3 = {val x = 2; _.toDouble * x}: (Int)=>Double

Notice how "_.toDouble * x" is simply the last statement of the block
and, thus, its return value. Since "_.toDouble" is a function, the
block returns a function.

> I can only understand this case:
>
>    val s = {1 + 2; "a" + "b"}
>
> Because everything needs to have a value, this is syntactical sugar for:
>
>    1 + 2
>    val s = "a" + "b"
>
>
> By the way; how many ways to define a function exist in Scala?

I think four ways:

val f = new Function1[Int, Int] { // Standard object instantiation
def apply(x: Int) = x * 2
}
val g = (x: Int) => x * 2 // (params) => bodyu
val h: Int => Int = _ * 2 // Using "_" for anonymous parameters --
its type must be either inferable or declared
val i: Int => Int = { // A block of case statements where a function
or partial function is expected is treated as a match
case even if even % 2 == 0 => even + 1
case odd => odd * 2
}

On 12/07/2011 00:05, Daniel Sobral wrote:
> To put it simply, The use of {} -- with a couple of exceptions --
> indicates a block of code, which is composed of multiple statements
> and declarations, and whose value is that of the last statement. As
> far as I can remember, and seems confirmed by a brief test, that is no
> different than in C, though I can hardly recall seeing them used like
> this.

It is the same indeed, except that in C/C++, a block has no value.
And you cannot pass a block as parameter of a (partial) function!

> They can be used instead of () as delimiter for parameter lists of
> arity 1 (ie, one argument).

It is more confusing than useful in the given examples (like {1}).
But it can be useful in some other cases, particularly DSLs where you can write:
repeat(5) { some block of code } // well, that's using a partial function there...
or
someFunc { some variable processing, then; lastResult }

>> By the way; how many ways to define a function exist in Scala?
>
> I think four ways:

There is also the example given by Eike, which I haven't meet before:
val f1 = (_.toDouble): (Int)=>Double

Looks like after-the-fact typing (casting?), no?

If we extend the question to methods, there are some other ways...

BTW, as a newbie myself, thanks for the good explanations!

>> By the way; how many ways to define a function exist in Scala?

Not shure if this is a separate case and how should it be classified, but it works:

scala> (_: Int) match {case x => x * 2}
res1: (Int) => Int =

scala> res1(2)
res2: Int = 4

--
Eugen Labun

On 11/07/2011 23:50, Eike Welk wrote:
> By the way; how many ways to define a function exist in Scala?

You also have Implicit anonymous functions (as explained in
http://www.scala-lang.org/node/43 page), used as parameters of functions:

The expressions in the left column are each function values which expand to the anonymous
functions on their right.
_ + 1 x => x + 1
_ * _ (x1, x2) => x1 * x2
(_: int) * 2 (x: int) => (x: int) * 2
if (_) x else y z => if (z) x else y
_.map(f) x => x.map(f)
_.map(_ + 1) x => x.map(y => y + 1)

Thanks for your comprehensive answer!

Eike.

On Tue, Jul 12, 2011 at 05:59, Eugen Labun wrote:
>>> By the way; how many ways to define a function exist in Scala?
>
> Not shure if this is a separate case and how should it be classified, but it works:
>
> scala> (_: Int) match {case x => x * 2}
> res1: (Int) => Int =

Just anonymous function. "... match ..." is a statement like any
other, what makes it a function is the use of underscore as an
anomymous parameter.

>
> scala> res1(2)
> res2: Int = 4
>
> --
> Eugen Labun
>

On Tuesday 12.07.2011 11:24:24 Philippe Lhoste wrote:
> You also have Implicit anonymous functions (as explained in
> http://www.scala-lang.org/node/43 page), used as parameters of functions:
>
> The expressions in the left column are each function values which expand to
> the anonymous functions on their right.
> _ + 1 x => x + 1
> _ * _ (x1, x2) => x1 * x2
> (_: int) * 2 (x: int) => (x: int) * 2
> if (_) x else y z => if (z) x else y
> _.map(f) x => x.map(f)
> _.map(_ + 1) x => x.map(y => y + 1)

Thank you! This seems to be the general mechanism of this underscore syntax.

It looks very odd to me, but the simple cases can be very well understood
without knowing the details:

val l = List(1, 2, 3)
val m = l map {_.toString}

When I saw something like this for the first time I thought: Scratch head,
scratch head; all elements of the list are probably converted to strings,
through some magic.

Eike.

On Tue, Jul 12, 2011 at 14:32, Eike Welk wrote:
>
> It looks very odd to me, but the simple cases can be very well understood
> without knowing the details:
>
>  val l = List(1, 2, 3)
>  val m = l map {_.toString}
>
> When I saw something like this for the first time I thought: Scratch head,
> scratch head; all elements of the list are probably converted to strings,
> through some magic.

It is strange indeed. I bet most of the people who look at Scala and
think "it's ugly!", these underscores are the reason. Once you do get
used to them, they start to make sense.

On Tue, Jul 12, 2011 at 11:02 AM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:

On Tue, Jul 12, 2011 at 14:32, Eike Welk <eike [dot] welk [at] gmx [dot] net> wrote:
>
> It looks very odd to me, but the simple cases can be very well understood
> without knowing the details:
>
>  val l = List(1, 2, 3)
>  val m = l map {_.toString}

When I tried this in the REPL, I was a bit surprised that it works with either parentheses or curly braces around _.toString, but it doesn't work with just plain _.toString. Can someone explain that, or should the reason be obvious?

--Russ P.

--
http://RussP.us

On Tue, Jul 12, 2011 at 16:09, Russ Paielli wrote:
> On Tue, Jul 12, 2011 at 11:02 AM, Daniel Sobral wrote:
>>
>> On Tue, Jul 12, 2011 at 14:32, Eike Welk wrote:
>> >
>> > It looks very odd to me, but the simple cases can be very well
>> > understood
>> > without knowing the details:
>> >
>> >  val l = List(1, 2, 3)
>> >  val m = l map {_.toString}
>>
>
> When I tried this in the REPL, I was a bit surprised that it works with
> either parentheses or curly braces around _.toString, but it doesn't work
> with just plain _.toString. Can someone explain that, or should the reason
> be obvious?

Obviousness is in the eye of the beholder.

When using underscore to create an anonymous function, there's a
question of where the boundaries of that function are. For instance,
there are three possible interpretations for that line (without
parenthesis):

x => val m = l map x.toString
val m = x => l map x.toString
val m = l map (x => x.toString)

I use parenthesis in the last one to indicate the whole function is a
parameter to map.

Well, anyway, Scala puts the function boundaries on the closest
enclosing expression delimiter, with one exception: if the underscore
is in the place of a parameter (being the only thing there), then it
means a partially applies function (or method). I'll put an example.
So, anyway, here are some examples:

val m = l map _.toString // val m = x => l map x.toString, with
assignment being an expression delimiter
m += l map _.toString // x => m += map _.toString, as = is not an
assignment anymore
val m = l map (_.toString) // val m = l map (x => x.toString), with
parenthesis serving as expression delimiter
val m = l indexWhere (_ == l.head, 1) // val m = l indexWhere (x => x
== l.head, 1), with parenthesis and comma serving as delimiter
val m = l grouped (_) // val m = x => l grouped (x), with _ standing
for partially applied method

> >  val l = List(1, 2, 3)
> >  val m = l map {_.toString}
> >
> > When I saw something like this for the first time I thought: Scratch
> > head, scratch head; all elements of the list are probably converted
> > to strings,

Well done, you are right!

> > through some magic.

Ahem, why this additional assumption?

From this point of view every syntax transformation done by the compiler
is "magic".
(Say: When you see for (Myclass i : somecol) { ... } in Java, it then
seems that the iterator of somecol is applied "through some magic").

> It is strange indeed. I bet most of the people who look at Scala and
> think "it's ugly!", these underscores are the reason.

I would say, underscores are the reason, but not so much in the
above example.
The underscore does much more look like a placeholder than
e.g. the Groovy "magic" that introduces the argument 'it' implicitly.
I found that much more confusing to see references to a seemingly
real named variable that was never defined.

> Once you do get used to them, they start to make sense.

True, as for any syntactical language feature ;-)

KR
Det

On Wednesday 13.07.2011 09:22:50 Detering Dirk wrote:
> > > val l = List(1, 2, 3)
> > > val m = l map {_.toString}
> > >
> > > When I saw something like this for the first time I thought: Scratch
> > > head, scratch head; all elements of the list are probably converted
> > > to strings,
>
> Well done, you are right!
>
> > > through some magic.
>
> Ahem, why this additional assumption?

I could as well have written: "... through some mechanism that I don't
understand." But my point was that you can still understand the program, even
if you don't fully understand the mechanism. This IMHO shows that this feature
of the language is fairly well designed. But it's hard to google for it.

Had I seen this the day before yesterday:

val l = List(1, 2, 3)
val n = l reduce {_+_}

I would have thought: "{_+_}" Japanese smiley? Sleepy bunny with earphones?

A real Japanese emoticon that is legal Scala would have been more elegant in
my example; but I can't come up with one.

Eike.