forbidding “dangling” local blocks in scala

If you start putting the brace on the ends of the line instead of on
the next line, you will magically find that you don't care about local
blocks anymore. I don't think I use local resultless blocks in Scala,
but I don't see a reason to make a block invalid if its result is not
consumed, just as writing foo.bar(baz) is not invalid if its result is
not consumed.

var x = 5
var y = x * 2
println(x + foo(y))

x = 10
y = x * 2
println(x + bar(y))

would be better written using local blocks:

{
val x = 5
val y = x * 2
println(x + foo(y))
}

{
val x = 10
val y = x * 2
println(x + bar(y))
}

It's hardly a compelling case, but then, the practice of placing the {
on the next line isn't very compelling either. It emphasises
structure more than content.
2009/10/7 Elazar Leibovich :
> [asked on StackOverflow before, as I thought there's something simple
> I'm missing]
> In scala it is possible to define a local block in a function. The
> local block evaluates to the last statements, for example,
>
> val x = {val x =1;x+1}
>
> Here x==2, the inner val x is local to that block.
>
> However those local blocks can cause sneaky bugs when writing
> anonymous classes. For example (from scala's reference)
>
> new Iterator[Int]
> {...} // new anonymous class inheriting from Iterator[Int]
>
> new Iterator[Int]
>
> {...} //new Iterator[Int] followed by a "dangling" local block
>
> Differntiating between the two cases is frustrating. Sometimes those
> two code snippets can compile, for instance if instead of
> Iterator[Int], Range(0,1,1) is used.
>
> I thought about it and couldn't find a case where "dangling" local
> block (ie, a local block whose value isn't use) is needed (or makes
> the code more elegant).
>
> Is there a case where we want a local block, without using its value
> (and without putting it in a different function and calling this
> function)? I'll be glad for an example.
>
> If not, I think it would be nice to issue a warning (or even forbid
> altogther) whenever scalac encounter "dangling" local block. Am I
> missing something?
>

The problem here is the ambiguity of the local blocks. When their
output is used - you know for sure they are local blocks. Otherwise
they might be other things, such as anonymous class.

On Wed, Oct 7, 2009 at 8:29 AM, Ricky Clarkson wrote:
> If you start putting the brace on the ends of the line instead of on
> the next line, you will magically find that you don't care about local
> blocks anymore.  I don't think I use local resultless blocks in Scala,
> but I don't see a reason to make a block invalid if its result is not
> consumed, just as writing foo.bar(baz) is not invalid if its result is
> not consumed.
>
> var x = 5
> var y = x * 2
> println(x + foo(y))
>
> x = 10
> y = x * 2
> println(x + bar(y))
>
> would be better written using local blocks:
>
> {
>  val x = 5
>  val y = x * 2
>  println(x + foo(y))
> }
>
> {
>  val x = 10
>  val y = x * 2
>  println(x + bar(y))
> }
>
> It's hardly a compelling case, but then, the practice of placing the {
> on the next line isn't very compelling either.  It emphasises
> structure more than content.
> 2009/10/7 Elazar Leibovich :
>> [asked on StackOverflow before, as I thought there's something simple
>> I'm missing]
>> In scala it is possible to define a local block in a function. The
>> local block evaluates to the last statements, for example,
>>
>> val x = {val x =1;x+1}
>>
>> Here x==2, the inner val x is local to that block.
>>
>> However those local blocks can cause sneaky bugs when writing
>> anonymous classes. For example (from scala's reference)
>>
>> new Iterator[Int]
>> {...} // new anonymous class inheriting from Iterator[Int]
>>
>> new Iterator[Int]
>>
>> {...} //new Iterator[Int] followed by a "dangling" local block
>>
>> Differntiating between the two cases is frustrating. Sometimes those
>> two code snippets can compile, for instance if instead of
>> Iterator[Int], Range(0,1,1) is used.
>>
>> I thought about it and couldn't find a case where "dangling" local
>> block (ie, a local block whose value isn't use) is needed (or makes
>> the code more elegant).
>>
>> Is there a case where we want a local block, without using its value
>> (and without putting it in a different function and calling this
>> function)? I'll be glad for an example.
>>
>> If not, I think it would be nice to issue a warning (or even forbid
>> altogther) whenever scalac encounter "dangling" local block. Am I
>> missing something?
>>
>
>
>
> --
> Ricky Clarkson
> Java Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>

Also, if you place the opening brace on the same line, code is easier to pate into the REPL.

On Wed, Oct 7, 2009 at 9:20 AM, Elazar Leibovich <elazarl [at] gmail [dot] com> wrote:

The problem here is the ambiguity of the local blocks. When their
output is used - you know for sure they are local blocks. Otherwise
they might be other things, such as anonymous class.

On Wed, Oct 7, 2009 at 8:29 AM, Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] com> wrote:
> If you start putting the brace on the ends of the line instead of on
> the next line, you will magically find that you don't care about local
> blocks anymore.  I don't think I use local resultless blocks in Scala,
> but I don't see a reason to make a block invalid if its result is not
> consumed, just as writing foo.bar(baz) is not invalid if its result is
> not consumed.
>
> var x = 5
> var y = x * 2
> println(x + foo(y))
>
> x = 10
> y = x * 2
> println(x + bar(y))
>
> would be better written using local blocks:
>
> {
>  val x = 5
>  val y = x * 2
>  println(x + foo(y))
> }
>
> {
>  val x = 10
>  val y = x * 2
>  println(x + bar(y))
> }
>
> It's hardly a compelling case, but then, the practice of placing the {
> on the next line isn't very compelling either.  It emphasises
> structure more than content.
> 2009/10/7 Elazar Leibovich <elazarl [at] gmail [dot] com>:
>> [asked on StackOverflow before, as I thought there's something simple
>> I'm missing]
>> In scala it is possible to define a local block in a function. The
>> local block evaluates to the last statements, for example,
>>
>> val x = {val x =1;x+1}
>>
>> Here x==2, the inner val x is local to that block.
>>
>> However those local blocks can cause sneaky bugs when writing
>> anonymous classes. For example (from scala's reference)
>>
>> new Iterator[Int]
>> {...} // new anonymous class inheriting from Iterator[Int]
>>
>> new Iterator[Int]
>>
>> {...} //new Iterator[Int] followed by a "dangling" local block
>>
>> Differntiating between the two cases is frustrating. Sometimes those
>> two code snippets can compile, for instance if instead of
>> Iterator[Int], Range(0,1,1) is used.
>>
>> I thought about it and couldn't find a case where "dangling" local
>> block (ie, a local block whose value isn't use) is needed (or makes
>> the code more elegant).
>>
>> Is there a case where we want a local block, without using its value
>> (and without putting it in a different function and calling this
>> function)? I'll be glad for an example.
>>
>> If not, I think it would be nice to issue a warning (or even forbid
>> altogther) whenever scalac encounter "dangling" local block. Am I
>> missing something?
>>
>
>
>
> --
> Ricky Clarkson
> Java Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

They can't be anonymous classes without new Typename before them.

2009/10/7 Elazar Leibovich :
> The problem here is the ambiguity of the local blocks. When their
> output is used - you know for sure they are local blocks. Otherwise
> they might be other things, such as anonymous class.
>
> On Wed, Oct 7, 2009 at 8:29 AM, Ricky Clarkson wrote:
>> If you start putting the brace on the ends of the line instead of on
>> the next line, you will magically find that you don't care about local
>> blocks anymore.  I don't think I use local resultless blocks in Scala,
>> but I don't see a reason to make a block invalid if its result is not
>> consumed, just as writing foo.bar(baz) is not invalid if its result is
>> not consumed.
>>
>> var x = 5
>> var y = x * 2
>> println(x + foo(y))
>>
>> x = 10
>> y = x * 2
>> println(x + bar(y))
>>
>> would be better written using local blocks:
>>
>> {
>>  val x = 5
>>  val y = x * 2
>>  println(x + foo(y))
>> }
>>
>> {
>>  val x = 10
>>  val y = x * 2
>>  println(x + bar(y))
>> }
>>
>> It's hardly a compelling case, but then, the practice of placing the {
>> on the next line isn't very compelling either.  It emphasises
>> structure more than content.
>> 2009/10/7 Elazar Leibovich :
>>> [asked on StackOverflow before, as I thought there's something simple
>>> I'm missing]
>>> In scala it is possible to define a local block in a function. The
>>> local block evaluates to the last statements, for example,
>>>
>>> val x = {val x =1;x+1}
>>>
>>> Here x==2, the inner val x is local to that block.
>>>
>>> However those local blocks can cause sneaky bugs when writing
>>> anonymous classes. For example (from scala's reference)
>>>
>>> new Iterator[Int]
>>> {...} // new anonymous class inheriting from Iterator[Int]
>>>
>>> new Iterator[Int]
>>>
>>> {...} //new Iterator[Int] followed by a "dangling" local block
>>>
>>> Differntiating between the two cases is frustrating. Sometimes those
>>> two code snippets can compile, for instance if instead of
>>> Iterator[Int], Range(0,1,1) is used.
>>>
>>> I thought about it and couldn't find a case where "dangling" local
>>> block (ie, a local block whose value isn't use) is needed (or makes
>>> the code more elegant).
>>>
>>> Is there a case where we want a local block, without using its value
>>> (and without putting it in a different function and calling this
>>> function)? I'll be glad for an example.
>>>
>>> If not, I think it would be nice to issue a warning (or even forbid
>>> altogther) whenever scalac encounter "dangling" local block. Am I
>>> missing something?
>>>
>>
>>
>>
>> --
>> Ricky Clarkson
>> Java Programmer, AD Holdings
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>>
>

I am also not happy with the ambiguity posed by local blocks.
They are definitely useful -- for instance if you need some local
variables during initialization that should not end up as object
fields.
But I also thought about we can find a clearer syntax. A thought about
requiring prefixing local blocks with `do' but that is in itself
ambiguous.

But maybe we can find a good name for a method in Predef. That is,
we'd introduce a method like `initialize' in Predef, defined as follows:

def initalize[U](op: U): Unit = ()

Then we'd deprecate local blocks in class and object templates,
and we'd require instead to write

initialize { ... }

This would work, except that I am not 100% sure yet whether initialize
is the best name. Are there other suggestions?

Cheers

I confess to doing the following, to be safe:...;{  ...}

How about just init instead of initialize, following the example of applets, provided this won't break any code containing methods having a conforming signature.
2009/10/7 martin odersky <martin [dot] odersky [at] epfl [dot] ch>

I am also not happy with the ambiguity posed by local blocks.
They are definitely useful -- for instance if you need some local
variables during initialization that should not end up as object
fields.
But I also thought about we can find a clearer syntax. A thought about
requiring prefixing local blocks with `do' but that is in itself
ambiguous.

But maybe we can find a good name for a method in Predef. That is,
we'd introduce a method like `initialize' in Predef, defined as follows:

 def initalize[U](op: U): Unit = ()

Then we'd deprecate local blocks in class and object templates,
and we'd require instead to write

 initialize { ... }

This would work, except that I am not 100% sure yet whether initialize
is the best name. Are there other suggestions?

Cheers

>>>>> "martin" == martin odersky writes:

martin> Then we'd deprecate local blocks in class and object templates,
martin> and we'd require instead to write

martin> initialize { ... }

martin> This would work, except that I am not 100% sure yet whether
martin> initialize is the best name. Are there other suggestions?

locally

Perform, block, localBlock, execute... The problem with most options is that they'll usually be too generic, and thus likely to clash, or too specific, and thus likely to be obscure.   Since they are somewhat rare, I'd err on the obscure side. My own vote would be localBlock.

On Wed, Oct 7, 2009 at 9:19 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

I am also not happy with the ambiguity posed by local blocks.
They are definitely useful -- for instance if you need some local
variables during initialization that should not end up as object
fields.
But I also thought about we can find a clearer syntax. A thought about
requiring prefixing local blocks with `do' but that is in itself
ambiguous.

But maybe we can find a good name for a method in Predef. That is,
we'd introduce a method like `initialize' in Predef, defined as follows:

 def initalize[U](op: U): Unit = ()

Then we'd deprecate local blocks in class and object templates,
and we'd require instead to write

 initialize { ... }

This would work, except that I am not 100% sure yet whether initialize
is the best name. Are there other suggestions?

Cheers

On Wed, Oct 7, 2009 at 5:01 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:

Perform, block, localBlock, execute... The problem with most options is that they'll usually be too generic, and thus likely to clash, or too specific, and thus likely to be obscure.  

resultOf ?
 

Since they are somewhat rare, I'd err on the obscure side. My own vote would be localBlock.

On Wed, Oct 7, 2009 at 9:19 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

I am also not happy with the ambiguity posed by local blocks.
They are definitely useful -- for instance if you need some local
variables during initialization that should not end up as object
fields.
But I also thought about we can find a clearer syntax. A thought about
requiring prefixing local blocks with `do' but that is in itself
ambiguous.

But maybe we can find a good name for a method in Predef. That is,
we'd introduce a method like `initialize' in Predef, defined as follows:

 def initalize[U](op: U): Unit = ()

Then we'd deprecate local blocks in class and object templates,
and we'd require instead to write

 initialize { ... }

This would work, except that I am not 100% sure yet whether initialize
is the best name. Are there other suggestions?

Cheers

On Wed, Oct 7, 2009 at 7:56 AM, Seth Tisue wrote:
>>>>>> "martin" == martin odersky writes:
>
>  martin> Then we'd deprecate local blocks in class and object templates,
>  martin> and we'd require instead to write
>
>  martin>   initialize { ... }
>
>  martin> This would work, except that I am not 100% sure yet whether
>  martin> initialize is the best name. Are there other suggestions?
>
> locally

+1

-1

This fixes half** of a small problem (if admittedly tricky) problem, at the
cost of breaking the "all expressions are equally usable anywhere, so long
as they type" invariant that Scala has heretofore maintained. Mercilessly
culling pointless inconsistencies is one of the things I like best about
Scala, and the core of my "Scala is actually easier to learn and master than
Java" pitch.

A better solution would be adding compile-time warnings for this, and
IDE-level automated code inspections, both optional.

**'half', because the same pattern can appear in method bodies.

--Dave Griffith

nuttycom wrote:
>
> On Wed, Oct 7, 2009 at 7:56 AM, Seth Tisue wrote:
>>>>>>> "martin" == martin odersky writes:
>>
>>  martin> Then we'd deprecate local blocks in class and object templates,
>>  martin> and we'd require instead to write
>>
>>  martin>   initialize { ... }
>>
>>  martin> This would work, except that I am not 100% sure yet whether
>>  martin> initialize is the best name. Are there other suggestions?
>>
>> locally
>
> +1
>
>

Sent from my iPhone

On Oct 7, 2009, at 17:45, Dave Griffith
wrote:

>
>
> -1
>
> This fixes half** of a small problem (if admittedly tricky) problem,
> at the
> cost of breaking the "all expressions are equally usable anywhere,
> so long
> as they type" invariant that Scala has heretofore maintained.
> Mercilessly
> culling pointless inconsistencies is one of the things I like best
> about
> Scala, and the core of my "Scala is actually easier to learn and
> master than
> Java" pitch.
>
> A better solution would be adding compile-time warnings for this, and
> IDE-level automated code inspections, both optional.
>
> **'half', because the same pattern can appear in method bodies.

Oh, yes, we'd need to address that as well. So initialize is certainly
wrong. --m
>
> --Dave Griffith
>
>
> nuttycom wrote:
>>
>> On Wed, Oct 7, 2009 at 7:56 AM, Seth Tisue wrote:
>>>>>>>> "martin" == martin odersky writes:
>>>
>>> martin> Then we'd deprecate local blocks in class and object
>>> templates,
>>> martin> and we'd require instead to write
>>>
>>> martin> initialize { ... }
>>>
>>> martin> This would work, except that I am not 100% sure yet whether
>>> martin> initialize is the best name. Are there other suggestions?
>>>
>>> locally
>>
>> +1
>>
>>
>

-1

All the keyword syntaxes suggested for this look like arbitrary special
cases to me. If you have to abuse a keyword then it should be something
simple like do { ... }, since there are so many potential situations in
which it could be used. initialize (and initialise) is definitely out.

+1 for "eval" </sarcasm>

On Thu, Oct 8, 2009 at 1:44 PM, Marcus Downing <marcus [at] minotaur [dot] it> wrote:

-1

All the keyword syntaxes suggested for this look like arbitrary special
cases to me. If you have to abuse a keyword then it should be something
simple like do { ... }, since there are so many potential situations in
which it could be used. initialize (and initialise) is definitely out.
--
View this message in context: http://www.nabble.com/forbidding-%E2%80%9Cdangling%E2%80%9D-local-blocks-in-scala-tp25781100p25802456.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

Sorry to get into the debate so late. Would "private" introduce any
grammar ambiguity?

Martin Voelkle

On Thu, Oct 8, 2009 at 1:51 PM, Viktor Klang wrote:
> +1 for "eval"
>
> On Thu, Oct 8, 2009 at 1:44 PM, Marcus Downing wrote:
>>
>> -1
>>
>> All the keyword syntaxes suggested for this look like arbitrary special
>> cases to me. If you have to abuse a keyword then it should be something
>> simple like do { ... }, since there are so many potential situations in
>> which it could be used. initialize (and initialise) is definitely out.
>> --
>> View this message in context:
>> http://www.nabble.com/forbidding-%E2%80%9Cdangling%E2%80%9D-local-blocks...
>> Sent from the Scala - Debate mailing list archive at Nabble.com.
>>
>
>
>
> --
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder: http://groups.google.com/group/softpub
>

If you'll use private you won't be able to implement it as a part of the standard library, which is, if I understand correctly, the suggested implementation.

On Sat, Oct 17, 2009 at 11:12 AM, Martin Voelkle <martin [dot] voelkle [at] gmail [dot] com> wrote:

Sorry to get into the debate so late. Would "private" introduce any
grammar ambiguity?

Martin Voelkle

On Thu, Oct 8, 2009 at 1:51 PM, Viktor Klang <viktor [dot] klang [at] gmail [dot] com> wrote:
> +1 for "eval" </sarcasm>
>
> On Thu, Oct 8, 2009 at 1:44 PM, Marcus Downing <marcus [at] minotaur [dot] it> wrote:
>>
>> -1
>>
>> All the keyword syntaxes suggested for this look like arbitrary special
>> cases to me. If you have to abuse a keyword then it should be something
>> simple like do { ... }, since there are so many potential situations in
>> which it could be used. initialize (and initialise) is definitely out.
>> --
>> View this message in context:
>> http://www.nabble.com/forbidding-%E2%80%9Cdangling%E2%80%9D-local-blocks-in-scala-tp25781100p25802456.html
>> Sent from the Scala - Debate mailing list archive at Nabble.com.
>>
>
>
>
> --
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder: http://groups.google.com/group/softpub
>