C style for loops in Scala with break and continue

I understand that "break" is now available in 2.8. Is that true? I gave it a try, and it was not found. Do I need to import something?

Also, I understand that "continue" is not available but can be implemented. I am porting code from Python that uses continue, and eliminating it is definitely a non-trivial matter. Where can I find a good implementation of "continue" that will work with "for" loops? Thanks.

Russ P.

--
http://RussP.us

It's inside an object or package object. scala.control.something, probably.

On Mon, Mar 1, 2010 at 6:19 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I understand that "break" is now available in 2.8. Is that true? I gave it a try, and it was not found. Do I need to import something?

Also, I understand that "continue" is not available but can be implemented. I am porting code from Python that uses continue, and eliminating it is definitely a non-trivial matter. Where can I find a good implementation of "continue" that will work with "for" loops? Thanks.

Russ P.

--
http://RussP.us

--
Daniel C. Sobral

I travel to the future all the time.

On Monday March 1 2010, Daniel Sobral wrote:
> On Mon, Mar 1, 2010 at 6:19 PM, Russ Paielli wrote:
> > I understand that "break" is now available in 2.8. Is that true? I
> > gave it a try, and it was not found. Do I need to import something?
> >
> > Also, I understand that "continue" is not available but can be
> > implemented. I am porting code from Python that uses continue, and
> > eliminating it is definitely a non-trivial matter. Where can I find
> > a good implementation of "continue" that will work with "for"
> > loops? Thanks.
> >
> > Russ P.
>
> It's inside an object or package object. scala.control.something,
> probably.

Actually, scala.util.control.Breaks (there's a small example of the use
in the ScalaDoc HTML).

There is no corresponding mechanism for "continue." But how important is
it that you have a continue facility?

while (notDone) {
doSomeStuff
if (condition)
continue
doMoreStuff
}

==>

while (notDone) {
doSomeStuff
if (!condition)
doMoreStuff
}

Anyway, here's a brief thread from a sister mailing list on the topic:
.
Keep in mind that the run-time cost to using exception for frequent
local control flow may not be negligible.

If you're creating a replacement system for production purposes, it
seems to me that you should write it in Scala, not mechanistically
transliterate it from its previous implementation. If you're manually
writing the Scala counterpart, you have to understand the old code
(locally) as you go, so producing good, idiomatic Scala seems no harder
than preserving constructs that are essentially foreign to the
language.

Randall Schulz

On Mon, Mar 1, 2010 at 1:48 PM, Randall R Schulz <rschulz@sonic.net> wrote:

There is no corresponding mechanism for "continue." But how important is
it that you have a continue facility?

while (notDone) {
 doSomeStuff
 if (condition)
   continue
 doMoreStuff
}

==>

while (notDone) {
 doSomeStuff
 if (!condition)
   doMoreStuff
}

If only life were so simple. I don't want to get into the details, but I have a loop with several "continues" and non-trivial calculations in between. It was written to parse text data files that are not always well formatted. And yes, I realize that "continue" is not required, but it is by far the simplest and cleanest way to deal with anomalies in these files. I am disappointed that Scala does not support it. (However, I am impressed enough with Scala otherwise, and the lack of "continue" is a relatively minor issue overall.)

 

Anyway, here's a brief thread from a sister mailing list on the topic:
<http://old.nabble.com/-scala--Break-and-Continue-using-Exceptions-td23839441.html>.
Keep in mind that the run-time cost to using exception for frequent
local control flow may not be negligible.

Yes, thanks, I am aware of that thread, but it does not work for "for" loops.

If you're creating a replacement system for production purposes, it
seems to me that you should write it in Scala, not mechanistically
transliterate it from its previous implementation. If you're manually
writing the Scala counterpart, you have to understand the old code
(locally) as you go, so producing good, idiomatic Scala seems no harder
than preserving constructs that are essentially foreign to the
language.

Great idea! So, when can you start working on it?

Russ P.

--
http://RussP.us

On Monday March 1 2010, Russ Paielli wrote:
> ...
>
> If you're creating a replacement system for production purposes, it
>
> > seems to me that you should write it in Scala, not mechanistically
> > transliterate it from its previous implementation. If you're
> > manually writing the Scala counterpart, you have to understand the
> > old code (locally) as you go, so producing good, idiomatic Scala
> > seems no harder than preserving constructs that are essentially
> > foreign to the language.
>
> Great idea! So, when can you start working on it?

We need to talk terms, first.

> Russ P.

Randall Schulz

>>>>> "Russ" == Russ Paielli writes:

Russ> If only life were so simple. I don't want to get into the
Russ> details, but I have a loop with several "continues" and
Russ> non-trivial calculations in between.

I guess the very long thread we had on this exact subject in March 2009
didn't convince you... :-(

If anyone cares, the old thread is split across:
http://old.nabble.com/continue-keyword-td22566052.html
http://old.nabble.com/-Fwd:-Re:-continue-keyword--td22606705.html

I'm not sure I really expect anyone to reread all that, but I just want
to point out that the subject has already been thoroughly chewed over.

I'll quote myself:

>I don't actually have a strong feeling one way or the other
>about whether "break" or "continue" should be in the language (or in the
>standard library). I already conceded that this example is a pretty
>good one for wanting "break". The real point I want to make is that if
>you are routinely using "break" and "continue" in multiple places in
>long, complex loops, you are probably writing code which is difficult
>for other people to understand and nightmarish for other people to
>maintain and modify. That's why I consider it relatively unimportant
>whether or not Scala gets "break" and "continue".

I think this all still applies. And really, the case for "continue" in
particular, as opposed to "break", is really weak.

And I'll quote myself one more time:

>I used to use break and continue all the time in Java. Learning to do
>without them in Scala required a period of mental adjustment. Today, I
>write loops in Scala all the time and the idea of using break or
>continue almost never even occurs to me.

To me, the issue is largely one of aesthetics. In this case, I am reading lines of text and processing them, and I need to handle several possible anomalies. I don't know if the files I am reading from were even designed to be read automatically. Those anomalies and variations cannot be determined until I do some processing. I just don't like to see an "if" block and new level of indentation for each possible reason to abort a line of input. I just want to dispense with it as simply as possible and move on to the next line. To my way of thinking, a new level of indentation for each possible problem is less elegant. But I don't claim to be a language design expert. If someone can explain the problem with "continue," I am willing to listen.

Russ P.

I still think breaking that loop up into several methods and functions and using separate objects and some form of build pattern is always preferable to using break and continue. Both are kind of like GOTO and in complex cases result in hard to understand and unmaintainable code.
Take it as a chance to actually refactor your code into something more clean and workable. Don't forget that you can use higher kinded functions in scala.

- Stefan

2010/3/1 Russ Paielli <russ.paielli@gmail.com>

To me, the issue is largely one of aesthetics. In this case, I am reading lines of text and processing them, and I need to handle several possible anomalies. I don't know if the files I am reading from were even designed to be read automatically. Those anomalies and variations cannot be determined until I do some processing. I just don't like to see an "if" block and new level of indentation for each possible reason to abort a line of input. I just want to dispense with it as simply as possible and move on to the next line. To my way of thinking, a new level of indentation for each possible problem is less elegant. But I don't claim to be a language design expert. If someone can explain the problem with "continue," I am willing to listen.

Russ P.

> To me, the issue is largely one of aesthetics. In this case, I am reading lines of text and processing them, and I need to handle several possible anomalies. I don't know if the files I am reading from were even designed to be read automatically. Those anomalies and variations cannot be determined until I do some processing. I just don't like to see an "if" block and new level of indentation for each possible reason to abort a line of input. I just want to dispense with it as simply as possible and move on to the next line. To my way of thinking, a new level of indentation for each possible problem is less elegant. But I don't claim to be a language design expert. If someone can explain the problem with "continue," I am willing to listen.

I have no opinion about the merits of break and continue per se, but have you considered making use of exceptions to implement your pattern?

> val ce = new ContinueException()
> for(line <- file) {
> try {
> if(something is wrong with this line)
> throw ce
> } catch {
> case _: ContinueException => ()
> }
> }

My understanding is that such a pattern is pretty cheap, particularly if the object is pre-constructed and the throw and catch are in the same method. [1]

Niko

[1] http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive

Seth Tisue wrote:
>
>>>>>> "Russ" == Russ Paielli writes:
>>The real point I want to make is that if
>>you are routinely using "break" and "continue" in multiple places in
>>long, complex loops, you are probably writing code which is difficult
>>for other people to understand and nightmarish for other people to
>>maintain and modify. That's why I consider it relatively unimportant
>>whether or not Scala gets "break" and "continue".
>
> I think this all still applies. And really, the case for "continue" in
> particular, as opposed to "break", is really weak.
>
> And I'll quote myself one more time:
>
>>I used to use break and continue all the time in Java. Learning to do
>>without them in Scala required a period of mental adjustment. Today, I
>>write loops in Scala all the time and the idea of using break or
>>continue almost never even occurs to me.
>

I agree to all this when we talk about writing new code. But when you want
to port code from Java (or any other language L) you have two options:

1) rewrite it properly in Scala
2) do a straightforward L-to-Scala translation on a single-code-line level
or as close to this as possible.

Option 1) will give the most rewarding result but will probably take more
time to code and will certainly take more time to test. It will involve
swapping class hierarchies, control flow structure, container classes etc.
Therefore, it is the the high short term failure-risk option.

Option 2) is quick and mostly simple since the Scala language tool-set is
usually a superset of the L tool-set. It could therefore (mostly) even be
done automatically given good translators. That makes it the short term low
failure-risk option.
But the lack of break and continue breaks(!) the superset statement. It
causes the requirement for actual code restructuring (agreed, probably for
the best). I expect code that is produced by an automated translator that
supports break/continue elimination to be worse looking than Scala code with
breaks/continues in it, especially for cases where the break/continue is
nested inside multiple levels of conditional control flow.

For strategic libraries I prefer option 1) but for stuff that I will
probably need temporarily only (for example, just to prevent mixed
Java+Scala project issues) I tend to do 2).

My vote would be to add a break and continue but make it as ugly looking as
possible. Make us import it from a six-level-deep package and put lots of
underscores in the names used. Enable one-to-one translation but discourage
any use of these constructs in new code. Perhaps some form of
deprecated-since-birth logic could be used here :-)

2010/3/2 Russ Paielli <russ.paielli@gmail.com>

On Mon, Mar 1, 2010 at 1:48 PM, Randall R Schulz <rschulz@sonic.net> wrote:

There is no corresponding mechanism for "continue." But how important is
it that you have a continue facility?

while (notDone) {
 doSomeStuff
 if (condition)
   continue
 doMoreStuff
}

==>

while (notDone) {
 doSomeStuff
 if (!condition)
   doMoreStuff
}

If only life were so simple. I don't want to get into the details, but I have a loop with several "continues" and non-trivial calculations in between. It was written to parse text data files that are not always well formatted. And yes, I realize that "continue" is not required, but it is by far the simplest and cleanest way to deal with anomalies in these files. I am disappointed that Scala does not support it. (However, I am impressed enough with Scala otherwise, and the lack of "continue" is a relatively minor issue overall.)

How about:
import scala.util.control.Breaks._
for (i <- 1 to 15) {  breakable {     if (i % 3 == 0) break    if (i % 5 == 0) break     println(i)  }}
You only need a single extra nesting, to handle all your continue's (with breaks).
Dimitris 

 

Anyway, here's a brief thread from a sister mailing list on the topic:
<http://old.nabble.com/-scala--Break-and-Continue-using-Exceptions-td23839441.html>.
Keep in mind that the run-time cost to using exception for frequent
local control flow may not be negligible.

Yes, thanks, I am aware of that thread, but it does not work for "for" loops.

If you're creating a replacement system for production purposes, it
seems to me that you should write it in Scala, not mechanistically
transliterate it from its previous implementation. If you're manually
writing the Scala counterpart, you have to understand the old code
(locally) as you go, so producing good, idiomatic Scala seems no harder
than preserving constructs that are essentially foreign to the
language.

Great idea! So, when can you start working on it?

Russ P.

--
http://RussP.us

Text processing code throwing exceptions when processing lines? That's very, very bad. And, by the way, is how break works.

On Tue, Mar 2, 2010 at 6:35 AM, Niko Matsakis <niko@alum.mit.edu> wrote:

> To me, the issue is largely one of aesthetics. In this case, I am reading lines of text and processing them, and I need to handle several possible anomalies. I don't know if the files I am reading from were even designed to be read automatically. Those anomalies and variations cannot be determined until I do some processing. I just don't like to see an "if" block and new level of indentation for each possible reason to abort a line of input. I just want to dispense with it as simply as possible and move on to the next line. To my way of thinking, a new level of indentation for each possible problem is less elegant. But I don't claim to be a language design expert. If someone can explain the problem with "continue," I am willing to listen.

I have no opinion about the merits of break and continue per se, but have you considered making use of exceptions to implement your pattern?

> val ce = new ContinueException()
> for(line <- file) {
>   try {
>      if(something is wrong with this line)
>         throw ce
>   } catch {
>       case _: ContinueException => ()
>   }
> }

My understanding is that such a pattern is pretty cheap, particularly if the object is pre-constructed and the throw and catch are in the same method. [1]


Niko

[1] http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive

--
Daniel C. Sobral

I travel to the future all the time.

Dimitris Andreou wrote:
>
> How about:
>
> import scala.util.control.Breaks._
>
> for (i <- 1 to 15) {
> breakable {
> if (i % 3 == 0) break
> if (i % 5 == 0) break
> println(i)
> }
> }
>
> You only need a single extra nesting, to handle all your continue's (with
> breaks).
>

Doesn't that turn all actual breaks into continues?

2010/3/2 Silvio Bierman <sbierman@jambo-software.com>

Dimitris Andreou wrote:
>
> How about:
>
> import scala.util.control.Breaks._
>
> for (i <- 1 to 15) {
>   breakable {
>     if (i % 3 == 0) break
>     if (i % 5 == 0) break
>     println(i)
>   }
> }
>
> You only need a single extra nesting, to handle all your continue's (with
> breaks).
>

Doesn't that turn all actual breaks into continues?

Good point, this breaks (no pun) Tennent's Correspondence Principle (http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html). Still, it can be handy when no breaks are needed, but just continues. Any better "continue" simulation?

--
View this message in context: http://old.nabble.com/break-and-continue-tp27749190p27757442.html
Sent from the Scala - User mailing list archive at Nabble.com.

If you really need this flow layout because you have so many breaks and continues (and it's not performance-critical), you can do it yourself with something like

object Continue extends Exception { }
object Break extends Exception { }

try {
  for (i <- 0 to 10) {
    try {
      // Blah blah blah
      throw Continue
    }
    catch { case Continue => }
  }
}
catch { case Break => }

with "only" two extra indentations.

Alternatively, you can wrap your loop in a method and use "return" as equivalent to "break", and use the new "break" as "continue" (as Dimitris suggested).

  --Rex
     

On Mon, Mar 1, 2010 at 4:19 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I understand that "break" is now available in 2.8. Is that true? I gave it a try, and it was not found. Do I need to import something?

Also, I understand that "continue" is not available but can be implemented. I am porting code from Python that uses continue, and eliminating it is definitely a non-trivial matter. Where can I find a good implementation of "continue" that will work with "for" loops? Thanks.

Russ P.

--
http://RussP.us

while (notDone) {
doSomeStuff
if (condition)
continue
doMoreStuff
}

===>

@tailrec
def loop(done): Unit = {
if (done) {
return // break
}
doSomeStuff
if (condition) {
loop(done) // continue
}
doMoreStuff
}

On Wed, Mar 3, 2010 at 12:25 AM, Rex Kerr wrote:
> If you really need this flow layout because you have so many breaks and
> continues (and it's not performance-critical), you can do it yourself with
> something like
>
> object Continue extends Exception { }
> object Break extends Exception { }
>
> try {
>   for (i <- 0 to 10) {
>     try {
>       // Blah blah blah
>       throw Continue
>     }
>     catch { case Continue => }
>   }
> }
> catch { case Break => }
>
> with "only" two extra indentations.
>
> Alternatively, you can wrap your loop in a method and use "return" as
> equivalent to "break", and use the new "break" as "continue" (as Dimitris
> suggested).
>
>   --Rex
>
>
> On Mon, Mar 1, 2010 at 4:19 PM, Russ Paielli wrote:
>>
>> I understand that "break" is now available in 2.8. Is that true? I gave it
>> a try, and it was not found. Do I need to import something?
>>
>> Also, I understand that "continue" is not available but can be
>> implemented. I am porting code from Python that uses continue, and
>> eliminating it is definitely a non-trivial matter. Where can I find a good
>> implementation of "continue" that will work with "for" loops? Thanks.
>>
>> Russ P.
>>
>> --
>> http://RussP.us
>
>

After experimenting a bit with the break/continue thing, I had a deja vu experience and recalled that I had solved this problem (with the help of others on this list) about a year ago. I seem to have misplaced the code, so I took a peek at the implementation of "break" in 2.8, and I came up with my own version that includes "continue." Some of you will probably consider this an abomination, but it suits my needs:

class Break { // implementation of "break" and "continue"

    private class Break extends RuntimeException
    private class Continue extends RuntimeException

    def break { throw new Break }
    def continue { throw new Continue }

    def breaks(op: => Unit) {
        try { op } catch { case ex: Break => } }

    def continues(op: => Unit) {
        try { op } catch { case ex: Continue => } }
    }

Here's an example of how it is used:

import Break._

object BreakTest {

    def main(args: Array[String]) {

        println

        breaks { for (i <- 0 to 10) continues {

            if (i > 6) break
            println(i)
            if (i > 2) continue
            println(1000+i)
            }}

        println("\ncompleted successfully\n")
        }
    }

I see that the "official" 2.8 implementation of "break" uses "ControlException" like this:

private class BreakException extends RuntimeException with ControlException

I couldn't figure out what that does, so I eliminated it in my version. Also, the official version has this:

      case ex: BreakException =>
        if (ex ne breakException) throw ex

Again, I couldn't figure out what the "ne" check accomplishes, so I removed it.

Russ P.

On Tuesday March 2 2010, Russ Paielli wrote:
> ...
>
> class Break { // implementation of "break" and "continue"
>
> private class Break extends RuntimeException
> private class Continue extends RuntimeException
>
> def break { throw new Break }
> def continue { throw new Continue }

You really need to either reuse a single instace of each (or one per
block, if they're to nest) of these or override the fillInStackTrace()
method with a do-nothing, or you'll find this technique to be
excessively overhead-laden. fillInStackTrace() is by far the most
costly part of the JVM exception handling mechanism.

> def breaks(op: => Unit) {
> try { op } catch { case ex: Break => } }
>
> def continues(op: => Unit) {
> try { op } catch { case ex: Continue => } }
> }
>
> ...
>
> I see that the "official" 2.8 implementation of "break" uses
> "ControlException" like this:
>
> private class BreakException extends RuntimeException with
> ControlException
>
> I couldn't figure out what that does, so I eliminated it in my
> version. Also, the official version has this:
>
> case ex: BreakException =>
> if (ex ne breakException) throw ex

Here you see the dependence on a specific instance of BreakException
that is allocated once for each Breaks instance, allowing them to be
nested without interfering with each other.

Unfortunately, the Scala library code does not override
fillInStackTrace(), so ever Breaks created incurs the cost of calling
the stock fillInStackTrace().

> Again, I couldn't figure out what the "ne" check accomplishes, so I
> removed it.

"... I couldn't figure out what it did, so I removed it" ???

> Russ P.

Randall Schulz

Thanks for the feedback, but I'm not sure I understand what you are saying. You raised a concern about nesting, so I enhanced my little test to include nesting:

import Break._

object BreakTest {

    def main(args: Array[String]) {

        println

        breaks { for (i <- 0 to 5) continues {

            println
            if (i > 3) break
            println("i = " + i)
            if (i > 1) continue
            println("i = " + (1000+i))
            println

            breaks { for (j <- 0 to 5) continues {

                if (j > 3) break
                println("j = " + j)
                if (j > 1) continue
                println("j = " + (1000+j))
                }}
            }}

        println("\ncompleted successfully\n")
        }
    }

It still seems to work at expected, so I conclude that nesting is not a problem. Am I still missing something?

Also, I realized that I don't need create a Break class and then an object. I only need the object:

object Break { // implementation of "break" and "continue"

    private class Break extends RuntimeException
    private class Continue extends RuntimeException

    def break { throw new Break }
    def continue { throw new Continue }

    def breaks(op: => Unit) {
        try { op } catch { case ex: Break => } }

    def continues(op: => Unit) {
        try { op } catch { case ex: Continue => } }
    }

Russ P.


On Tue, Mar 2, 2010 at 1:21 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Tuesday March 2 2010, Russ Paielli wrote:
> ...
>
> class Break { // implementation of "break" and "continue"
>
>     private class Break extends RuntimeException
>     private class Continue extends RuntimeException
>
>     def break { throw new Break }
>     def continue { throw new Continue }

You really need to either reuse a single instace of each (or one per
block, if they're to nest) of these or override the fillInStackTrace()
method with a do-nothing, or you'll find this technique to be
excessively overhead-laden. fillInStackTrace() is by far the most
costly part of the JVM exception handling mechanism.


>     def breaks(op: => Unit) {
>         try { op } catch { case ex: Break => } }
>
>     def continues(op: => Unit) {
>         try { op } catch { case ex: Continue => } }
>     }
>
> ...
>
> I see that the "official" 2.8 implementation of "break" uses
> "ControlException" like this:
>
> private class BreakException extends RuntimeException with
> ControlException
>
> I couldn't figure out what that does, so I eliminated it in my
> version. Also, the official version has this:
>
>       case ex: BreakException =>
>         if (ex ne breakException) throw ex

Here you see the dependence on a specific instance of BreakException
that is allocated once for each Breaks instance, allowing them to be
nested without interfering with each other.

Unfortunately, the Scala library code does not override
fillInStackTrace(), so ever Breaks created incurs the cost of calling
the stock fillInStackTrace().


> Again, I couldn't figure out what the "ne" check accomplishes, so I
> removed it.

"... I couldn't figure out what it did, so I removed it"  ???


> Russ P.


Randall Schulz

--
http://RussP.us

>>>>> "Randall" == Randall R Schulz writes:

Randall> Unfortunately, the Scala library code does not override
Randall> fillInStackTrace(), so ever Breaks created incurs the cost of
Randall> calling the stock fillInStackTrace().

BreakException mixes in the ControlException trait, which includes the
NoStackTrace trait, which is self-explanatory.

On Tuesday March 2 2010, Seth Tisue wrote:
> >>>>> "Randall" == Randall R Schulz writes:
>
> Randall> Unfortunately, the Scala library code does not override
> Randall> fillInStackTrace(), so every Breaks created incurs the
> Randall> cost of calling the stock fillInStackTrace().
>
> BreakException mixes in the ControlException trait, which includes
> the NoStackTrace trait, which is self-explanatory.

OK. I didn't follow the inheritance chain all the way and missed that.

RRS

On Tue, Mar 2, 2010 at 2:33 PM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Randall" == Randall R Schulz <rschulz@sonic.net> writes:

 Randall> Unfortunately, the Scala library code does not override
 Randall> fillInStackTrace(), so ever Breaks created incurs the cost of
 Randall> calling the stock fillInStackTrace().

BreakException mixes in the ControlException trait, which includes the
NoStackTrace trait, which is self-explanatory.

Thanks for pointing that out. I have revised my code accordingly. I also made a couple of other minor simplifications. Not to offend anyone, but here is all you need to use "break" and "continue" in Scala:

import scala.util.control.ControlException // for efficiency

object Break { // implementation of "break" and "continue"

    private class Continue extends RuntimeException with ControlException
    private class Break    extends RuntimeException with ControlException

    def continues(op: => Unit) { try { op } catch { case e: Continue => }}
    def breaks   (op: => Unit) { try { op } catch { case e: Break => }}

    def continue { throw new Continue }
    def break    { throw new Break }
    }

/* example of usage:

import Break._

breaks { for (i <- 0 to 5) continues {
 
    if (i > 3) break
    println(i)
    if (i > 1) continue
    println(1000+i)
    }}

*/



--
http://RussP.us

I have recorded no metrics to prove this, but, as far as I can tell, my use of break/continue even in imperative Java code has been very minimal and if I were to peer review code that had a lot of those two constructs I would *probably* reject it.

On the other hand, now that I've been writing non-trivial apps in Scala, I find that when using idiomatic functional Scala even the very occasional need to resort to those two constructs has disappeared - they're relegated to that dark dingy place where I placed GOTO -- good riddance!

Ishaaq

On 3 March 2010 13:04, Russ Paielli <russ.paielli@gmail.com> wrote:

On Tue, Mar 2, 2010 at 2:33 PM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Randall" == Randall R Schulz <rschulz@sonic.net> writes:

 Randall> Unfortunately, the Scala library code does not override
 Randall> fillInStackTrace(), so ever Breaks created incurs the cost of
 Randall> calling the stock fillInStackTrace().

BreakException mixes in the ControlException trait, which includes the
NoStackTrace trait, which is self-explanatory.

Thanks for pointing that out. I have revised my code accordingly. I also made a couple of other minor simplifications. Not to offend anyone, but here is all you need to use "break" and "continue" in Scala:

import scala.util.control.ControlException // for efficiency

object Break { // implementation of "break" and "continue"

    private class Continue extends RuntimeException with ControlException
    private class Break    extends RuntimeException with ControlException

    def continues(op: => Unit) { try { op } catch { case e: Continue => }}
    def breaks   (op: => Unit) { try { op } catch { case e: Break => }}

    def continue { throw new Continue }
    def break    { throw new Break }
    }

/* example of usage:

import Break._

breaks { for (i <- 0 to 5) continues {
 
    if (i > 3) break
    println(i)
    if (i > 1) continue
    println(1000+i)
    }}

*/



--
http://RussP.us

On Tue, Mar 2, 2010 at 10:29 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

I have recorded no metrics to prove this, but, as far as I can tell, my use of break/continue even in imperative Java code has been very minimal and if I were to peer review code that had a lot of those two constructs I would *probably* reject it.

Well, I'm very grateful that I don't need to have my code reviewed by anyone like you. As far as I am concerned, break and continue are the best alternative for several problems I have had to solve.

The notion that every glitch in an input data file should dictate an extra block and extra level of indentation in my code for reading it doesn't seem like a good design philosophy to me.

 

On the other hand, now that I've been writing non-trivial apps in Scala, I find that when using idiomatic functional Scala even the very occasional need to resort to those two constructs has disappeared - they're relegated to that dark dingy place where I placed GOTO -- good riddance!

Break and continue are simply a clean and convenient way to handle certain kinds of exceptions. Do you reject exceptions too? Or are they more in style? The notion that break and continue are in any way comparable to "goto" is just silly.

If I ever review code that uses complicated extra blocks when a simple continue would suffice, I will reject it.

Russ P.

--
http://RussP.us

Hi all, Russ
As following this debate it seems to me that this is going into a not so
very nice direction.
Break and continue offer a way to solve your problem in java as now in
scala.
There are other options to solve this problem in scala some were suggested
here already.
I think also that some Kind of misunderstanding comes from the task
description, because the (apparrently) massiv scale of your problem it Might
Be helpfull to Know some more details.
For now i can only say that i would suggest you to Look also at the Lift/
Box / Either disscusion it seems at least related to your Problem.
Here :http://bit.ly/9Ys1jd
i Hope this helps, regards andreas

Whoever said anything about "complicated blocks" being the only viable alternative to break and continue? I think your problem is that you are insisting on writing in an imperative style in a language that was designed to offer you much greater power and conciseness when using it in its idiomatic functional style. In fact, if it were not for the fact that scala offers you the ability to marry the OO and functional styles elegantly together, it would be pretty much useless to learn it. You might as well stick to other traditional imperative languages - why even bother wasting your time?

And no, I don't think my comparison of continue and break to goto was silly - goto is an extreme case of the same problem - imperative code that jumps around causing the reader to switch context - it is annoyingly jarring to have to get your eyes to jump back and forth and keep track of multiple contexts. I concede that break and continue are not as bad as goto, but they do share the same problem, albeit to a lesser degree.

As for exceptions, when used judiciously, I don't find them a problem because they signify an error condition - which is usually not the case for most usages of break and continue.

I'll also point out that I was careful to temper my statement about code I would review - I said I would *probably* reject Java code that had a *lot* of those two constructs. My point was that with its functional power scala gives you even less of an excuse to have to resort to them. Am sure you can find counter-examples (even in scala) if you look hard enough - but I daresay the vast majority of instances where they are used can be written more elegantly in a functional style - and you'd run less of a danger of having edge-case errors.

But, I have a feeling you don't care. You're probably happy you got your problem solved the way you wanted to. Fair enough.

Regards,
Ishaaq

On 3 March 2010 18:26, Russ Paielli <russ.paielli@gmail.com> wrote:

On Tue, Mar 2, 2010 at 10:29 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

I have recorded no metrics to prove this, but, as far as I can tell, my use of break/continue even in imperative Java code has been very minimal and if I were to peer review code that had a lot of those two constructs I would *probably* reject it.

Well, I'm very grateful that I don't need to have my code reviewed by anyone like you. As far as I am concerned, break and continue are the best alternative for several problems I have had to solve.

The notion that every glitch in an input data file should dictate an extra block and extra level of indentation in my code for reading it doesn't seem like a good design philosophy to me.

 

On the other hand, now that I've been writing non-trivial apps in Scala, I find that when using idiomatic functional Scala even the very occasional need to resort to those two constructs has disappeared - they're relegated to that dark dingy place where I placed GOTO -- good riddance!

Break and continue are simply a clean and convenient way to handle certain kinds of exceptions. Do you reject exceptions too? Or are they more in style? The notion that break and continue are in any way comparable to "goto" is just silly.

If I ever review code that uses complicated extra blocks when a simple continue would suffice, I will reject it.

Russ P.

--
http://RussP.us

Say I have this (Perl -- sorry, that's the language I mostly use break/continue) code:
my $cnt = 0;while(<INPUT>) {  continue if /^\s*#/;   # Skip comments  continue if /^\s*$/;  # Skip blank lines   break if /^!#/;         # Ignore anything past !#  $cnt++;                # Count lines}
In Scala, it could be replaced with:
var cnt = 0; for {  line <- INPUT.getLines // Assumes INPUT is a Source  if ! (line matches "\\s*#.*")  if ! (line matches "\\s*")} {  if (line matches "!#.*")     return cnt  cnt += 1}cnt
The use of "return" means that has to be in a function by itself, instead of in the body of something (as is usual in Perl). That, however, is a style difference. The point is that this can be accomplished without break/continue, and without deep nesting.   
On Wed, Mar 3, 2010 at 4:26 AM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Tue, Mar 2, 2010 at 10:29 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

I have recorded no metrics to prove this, but, as far as I can tell, my use of break/continue even in imperative Java code has been very minimal and if I were to peer review code that had a lot of those two constructs I would *probably* reject it.

Well, I'm very grateful that I don't need to have my code reviewed by anyone like you. As far as I am concerned, break and continue are the best alternative for several problems I have had to solve.

The notion that every glitch in an input data file should dictate an extra block and extra level of indentation in my code for reading it doesn't seem like a good design philosophy to me.

 

On the other hand, now that I've been writing non-trivial apps in Scala, I find that when using idiomatic functional Scala even the very occasional need to resort to those two constructs has disappeared - they're relegated to that dark dingy place where I placed GOTO -- good riddance!

Break and continue are simply a clean and convenient way to handle certain kinds of exceptions. Do you reject exceptions too? Or are they more in style? The notion that break and continue are in any way comparable to "goto" is just silly.

If I ever review code that uses complicated extra blocks when a simple continue would suffice, I will reject it.

Russ P.

--
http://RussP.us

--
Daniel C. Sobral

I travel to the future all the time.

I guess I'm just a stubborn SOB. I've used "continue" for many years, and it just looks right to me. A filter makes sense to me if the test can be done at the very top, before any processing, but that is often not the case for me. It is not uncommon for me to detect an error in an input record (line of text) 20 lines into the processing block. When I detect such an error, the last thing I want to do is to restructure my code to handle it when a single "continue" line will do the job just fine.

By the way, I see a lot of benefits to Scala even without functional programming. Compared to Python (which I am currently porting from), it is much faster, for example. And I like the syntax and the type inferencing much better than Java even if I never intended to use functional programming.

Russ P.


On Wed, Mar 3, 2010 at 2:46 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Whoever said anything about "complicated blocks" being the only viable alternative to break and continue? I think your problem is that you are insisting on writing in an imperative style in a language that was designed to offer you much greater power and conciseness when using it in its idiomatic functional style. In fact, if it were not for the fact that scala offers you the ability to marry the OO and functional styles elegantly together, it would be pretty much useless to learn it. You might as well stick to other traditional imperative languages - why even bother wasting your time?

And no, I don't think my comparison of continue and break to goto was silly - goto is an extreme case of the same problem - imperative code that jumps around causing the reader to switch context - it is annoyingly jarring to have to get your eyes to jump back and forth and keep track of multiple contexts. I concede that break and continue are not as bad as goto, but they do share the same problem, albeit to a lesser degree.

As for exceptions, when used judiciously, I don't find them a problem because they signify an error condition - which is usually not the case for most usages of break and continue.

I'll also point out that I was careful to temper my statement about code I would review - I said I would *probably* reject Java code that had a *lot* of those two constructs. My point was that with its functional power scala gives you even less of an excuse to have to resort to them. Am sure you can find counter-examples (even in scala) if you look hard enough - but I daresay the vast majority of instances where they are used can be written more elegantly in a functional style - and you'd run less of a danger of having edge-case errors.

But, I have a feeling you don't care. You're probably happy you got your problem solved the way you wanted to. Fair enough.

Regards,
Ishaaq

On 3 March 2010 18:26, Russ Paielli <russ.paielli@gmail.com> wrote:

On Tue, Mar 2, 2010 at 10:29 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

I have recorded no metrics to prove this, but, as far as I can tell, my use of break/continue even in imperative Java code has been very minimal and if I were to peer review code that had a lot of those two constructs I would *probably* reject it.

Well, I'm very grateful that I don't need to have my code reviewed by anyone like you. As far as I am concerned, break and continue are the best alternative for several problems I have had to solve.

The notion that every glitch in an input data file should dictate an extra block and extra level of indentation in my code for reading it doesn't seem like a good design philosophy to me.

 

On the other hand, now that I've been writing non-trivial apps in Scala, I find that when using idiomatic functional Scala even the very occasional need to resort to those two constructs has disappeared - they're relegated to that dark dingy place where I placed GOTO -- good riddance!

Break and continue are simply a clean and convenient way to handle certain kinds of exceptions. Do you reject exceptions too? Or are they more in style? The notion that break and continue are in any way comparable to "goto" is just silly.

If I ever review code that uses complicated extra blocks when a simple continue would suffice, I will reject it.

Russ P.

--
http://RussP.us

--
http://RussP.us

I guess the difference would be that I wouldn't be restructuring my code to handle the error in the first place as I would have written it differently to begin with. But, fair enough, since this is turning out to be very subjective, lets just agree to disagree :)

By the way, the speedup you're seeing is probably thanks to the JVM not scala itself. IMO performance is not necessarily enough of a reason to change languages - it might be interesting exercise for you to check out Jython and see if you get any speed up with it. In fact, with the next version of the JVM you'll see even greater speedups with dynamically typed languages like Jython and JRuby (assuming their implementations take advantage of the new invokedynamic bytecode in JDK 7).

Ishaaq

On 4 March 2010 05:51, Russ Paielli <russ.paielli@gmail.com> wrote:

I guess I'm just a stubborn SOB. I've used "continue" for many years, and it just looks right to me. A filter makes sense to me if the test can be done at the very top, before any processing, but that is often not the case for me. It is not uncommon for me to detect an error in an input record (line of text) 20 lines into the processing block. When I detect such an error, the last thing I want to do is to restructure my code to handle it when a single "continue" line will do the job just fine.

By the way, I see a lot of benefits to Scala even without functional programming. Compared to Python (which I am currently porting from), it is much faster, for example. And I like the syntax and the type inferencing much better than Java even if I never intended to use functional programming.

Russ P.


On Wed, Mar 3, 2010 at 2:46 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Whoever said anything about "complicated blocks" being the only viable alternative to break and continue? I think your problem is that you are insisting on writing in an imperative style in a language that was designed to offer you much greater power and conciseness when using it in its idiomatic functional style. In fact, if it were not for the fact that scala offers you the ability to marry the OO and functional styles elegantly together, it would be pretty much useless to learn it. You might as well stick to other traditional imperative languages - why even bother wasting your time?

And no, I don't think my comparison of continue and break to goto was silly - goto is an extreme case of the same problem - imperative code that jumps around causing the reader to switch context - it is annoyingly jarring to have to get your eyes to jump back and forth and keep track of multiple contexts. I concede that break and continue are not as bad as goto, but they do share the same problem, albeit to a lesser degree.

As for exceptions, when used judiciously, I don't find them a problem because they signify an error condition - which is usually not the case for most usages of break and continue.

I'll also point out that I was careful to temper my statement about code I would review - I said I would *probably* reject Java code that had a *lot* of those two constructs. My point was that with its functional power scala gives you even less of an excuse to have to resort to them. Am sure you can find counter-examples (even in scala) if you look hard enough - but I daresay the vast majority of instances where they are used can be written more elegantly in a functional style - and you'd run less of a danger of having edge-case errors.

But, I have a feeling you don't care. You're probably happy you got your problem solved the way you wanted to. Fair enough.

Regards,
Ishaaq

On 3 March 2010 18:26, Russ Paielli <russ.paielli@gmail.com> wrote:

On Tue, Mar 2, 2010 at 10:29 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

I have recorded no metrics to prove this, but, as far as I can tell, my use of break/continue even in imperative Java code has been very minimal and if I were to peer review code that had a lot of those two constructs I would *probably* reject it.

Well, I'm very grateful that I don't need to have my code reviewed by anyone like you. As far as I am concerned, break and continue are the best alternative for several problems I have had to solve.

The notion that every glitch in an input data file should dictate an extra block and extra level of indentation in my code for reading it doesn't seem like a good design philosophy to me.

 

On the other hand, now that I've been writing non-trivial apps in Scala, I find that when using idiomatic functional Scala even the very occasional need to resort to those two constructs has disappeared - they're relegated to that dark dingy place where I placed GOTO -- good riddance!

Break and continue are simply a clean and convenient way to handle certain kinds of exceptions. Do you reject exceptions too? Or are they more in style? The notion that break and continue are in any way comparable to "goto" is just silly.

If I ever review code that uses complicated extra blocks when a simple continue would suffice, I will reject it.

Russ P.

--
http://RussP.us

--
http://RussP.us