forbidding “dangling” local blocks in scala

[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]

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@...>:

> [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
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...

[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 <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 <elazarl@...>:
>> [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
> [phone]
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@...
>

[Viktor Klang]

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@...> 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.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 <elazarl@...>:
>> [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
> [phone]
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@...
>

--
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

[Ricky Clarkson]

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

2009/10/7 Elazar Leibovich <elazarl@...>:

> 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.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 <elazarl@...>:
>>> [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
>> [phone]
>> Skype: ricky_clarkson
>> Google Talk: ricky.clarkson@...
>>
>

--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...

[Martin Odersky]

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

[Rob Dickens-2]

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.odersky@...>

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

--
Rob, Lafros.com

[Seth Tisue]

>>>>> "martin" == martin odersky <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

--
Seth Tisue @ Northwestern University / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Daniel Sobral]

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.odersky@...> 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

 -- Martin

--
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.

[Viktor Klang]

On Wed, Oct 7, 2009 at 5:01 PM, Daniel Sobral <dcsobral@...> 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.odersky@...> 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

 -- Martin

--
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.

--
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

[nuttycom]

On Wed, Oct 7, 2009 at 7:56 AM, Seth Tisue <seth@...> wrote:

>>>>>> "martin" == martin odersky <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

[Dave Griffith]

-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 <[e-mail]> wrote:
>>>>>> "martin" == martin odersky <[e-mail]> 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

[martin odersky-2]

Sent from my iPhone

On Oct 7, 2009, at 17:45, Dave  Griffith <dave.l.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 <seth@...> wrote:
>>>>>>>> "martin" == martin odersky <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
>>
>>
>
> --
> View this message in context: http://www.nabble.com/forbidding-%E2%80%9Cdangling%E2%80%9D-local-blocks-in-scala-tp25781100p25789168.html
> Sent from the Scala - Debate mailing list archive at Nabble.com.
>

[Marcus Downing]

-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.

[Viktor Klang]

+1 for "eval" </sarcasm>

On Thu, Oct 8, 2009 at 1:44 PM, Marcus Downing <marcus@...> 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

[Martin Voelkle]

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.klang@...> wrote:

> +1 for "eval" </sarcasm>
>
> On Thu, Oct 8, 2009 at 1:44 PM, Marcus Downing <marcus@...> 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
>

[Elazar Leibovich]

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.voelkle@...> 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.klang@...> wrote:
> +1 for "eval" </sarcasm>
>
> On Thu, Oct 8, 2009 at 1:44 PM, Marcus Downing <marcus@...> 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
>