gmane.comp.lang.scala

Harshad | 15 Oct 21:56

The continue keyword

Hi,

Would it be possible to add support for the "continue" keyword? Note: there
has been discussion on a similar topic before [1]. But that dealt
with "continue" _and_ "break". From my limited knowledge it appears
that "continue" by itself should be much more straight forward to implement
than "break". We just need to jump to the position after the last operation
in the closest surrounding Unit (?)

Even if "break" is not actually supported, it might be easier to
emulate "break" when "continue" is supported. Eg,

// Java code
while (!done) {
  if (x) {
    if (y)
      break;
  }
  if (z)
    // blah blah
}

// Scala equivalent without continue / break
while (!done) {
  var yHit = false
  if (x) {
    if (y) {
      yHit = true
      done = true
    }

(Continue reading)

headers

Andrew Gaydenko | 15 Oct 22:40

Re: The continue keyword

On Wednesday 15 October 2008 23:59:29 Harshad wrote:
> Hi,
>
> Would it be possible to add support for the "continue" keyword? Note: there
> has been discussion on a similar topic before [1]. But that dealt
> with "continue" _and_ "break". From my limited knowledge it appears
> that "continue" by itself should be much more straight forward to implement
> than "break". We just need to jump to the position after the last operation
> in the closest surrounding Unit (?)
>
> Even if "break" is not actually supported, it might be easier to
> emulate "break" when "continue" is supported. Eg,
>
> // Java code
> while (!done) {
>   if (x) {
>     if (y)
>       break;
>   }
>   if (z)
>     // blah blah
> }
>
> // Scala equivalent without continue / break
> while (!done) {
>   var yHit = false
>   if (x) {
>     if (y) {
>       yHit = true
>       done = true

(Continue reading)

headers

David Pollak | 15 Oct 22:50

Re: The continue keyword

On Wed, Oct 15, 2008 at 1:40 PM, Andrew Gaydenko <a <at> gaydenko.com> wrote:

On Wednesday 15 October 2008 23:59:29 Harshad wrote:
> Hi,
>
> Would it be possible to add support for the "continue" keyword? Note: there
> has been discussion on a similar topic before [1]. But that dealt
> with "continue" _and_ "break". From my limited knowledge it appears
> that "continue" by itself should be much more straight forward to implement
> than "break". We just need to jump to the position after the last operation
> in the closest surrounding Unit (?)
>
> Even if "break" is not actually supported, it might be easier to
> emulate "break" when "continue" is supported. Eg,
>
> // Java code
> while (!done) {
> if (x) {
> if (y)
> break;
> }
> if (z)
> // blah blah
> }
>
> // Scala equivalent without continue / break
> while (!done) {
> var yHit = false
> if (x) {
> if (y) {
> yHit = true
> done = true
> }
> }
> if (!yHit) {
> if (z)
> // blah blah
> }
> }
>
> // Scala equivalent with continue
> while (!done) {
> if (x) {
> if (y)
> done = true
> continue // note that continue is now effectively a break
> }
> if (z)
> // blah blah
>
> }
>
> I hope this suggestion doesn't lead to a "functional v/s imperative"
> discussion, since Scala does boast support for both paradigms, and I am led
> to believe that imperative constructs are easier in certain situations.
>
>
> [1] http://thread.gmane.org/gmane.comp.lang.scala/3600/
>
> cheers,
> Harshad

Harshad,

I'm very "imperative" man, or Java-infected, or - you say It is
unbelievably, but I have not met a situation yet (during ~350-400KB of
exercises) when this or that fragment can not be written absolutely readable
(for my Java eyes) whithout 'break', 'continue' (and even 'return'!). Just use

- case matching,
- (!)short functions inside functions and
- tail recursion.

Believe, very quickly (well, days rather seconds) Java raw code will be awful
("very long and complicated") for your eyes Just climb first stair-step
(the first was most difficult for me, I'm not very young boy).

Another related comment. In Eclipse plugin I have selected red color for vars
(and green for vals). It's (again) strange, but many functions (and even
traits/classes) can be easely kept "without red". Those red-less
fragments/traits begin to work very quickly (I mean a time spent on
debugging).

You see, such brief confession

Andrew

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

headers

Erkki Lindpere | 16 Oct 21:52

Re: The continue keyword

I would also say I'm very "imperative" but I have found examples where I 
missed both break and continue.

I'm porting the JBox2D physics engine to Scala and there are some long 
solver functions which iterate over various things. In the Java version 
there was code like this (but in reality more complex cases):
for (...) {
  if (cond2) { continue }
  if (cond1) { continue }
  // tens or hundreds of lines of code follows
}

At first I replaced it with
for (... if !cond1 and !cond2) {...}

which is actually more readable I think, but this has HORRIBLE 
performance depending on the type of collection being filtered.

So the solution was to write an if inside that block which covered the 
whole block. This made for some quite deep nesting levels and for a 
method with hundred lines or more that doesn't look so good. Of course, 
the method probably could be broken up into smaller ones, but I try to 
keep the port as similar to the Java code as possible (unless the Scala 
way is clearly better).

Andrew Gaydenko wrote:
> I'm very "imperative" man, or Java-infected, or - you say  It is 
> unbelievably, but I have not met a situation yet (during ~350-400KB of 
> exercises) when this or that fragment can not be written absolutely readable 
> (for my Java eyes) whithout 'break', 'continue' (and even 'return'!). Just use

headers

Andrew Gaydenko | 16 Oct 22:22

Re: The continue keyword

On Thursday 16 October 2008 23:52:55 Erkki Lindpere wrote:
> I would also say I'm very "imperative" but I have found examples where I
> missed both break and continue.
>
> I'm porting the JBox2D physics engine to Scala and there are some long
> solver functions which iterate over various things. In the Java version
> there was code like this (but in reality more complex cases):
> for (...) {
>   if (cond2) { continue }
>   if (cond1) { continue }
>   // tens or hundreds of lines of code follows
> }
>
> At first I replaced it with
> for (... if !cond1 and !cond2) {...}
>
> which is actually more readable I think, but this has HORRIBLE
> performance depending on the type of collection being filtered.

probably 

coll.filter(i => !cond1(i) && !cond2(i)).foreach { item =>
  // deal with item
}

is faster?

> So the solution was to write an if inside that block which covered the
> whole block. This made for some quite deep nesting levels and for a
> method with hundred lines or more that doesn't look so good. Of course,
> the method probably could be broken up into smaller ones,

For me it is key approach - I can not think in terms of hundreds LOC 

> but I try to
> keep the port as similar to the Java code as possible (unless the Scala
> way is clearly better).
>
> Andrew Gaydenko wrote:
> > I'm very "imperative" man, or Java-infected, or - you say  It is
> > unbelievably, but I have not met a situation yet (during ~350-400KB of
> > exercises) when this or that fragment can not be written absolutely
> > readable (for my Java eyes) whithout 'break', 'continue' (and even
> > 'return'!). Just use

headers

Brett Knights | 16 Oct 22:53

Re: The continue keyword

Erkki Lindpere wrote:
>
> I would also say I'm very "imperative" but I have found examples where 
> I missed both break and continue.
>
> I'm porting the JBox2D physics engine to Scala and there are some long 
> solver functions which iterate over various things. In the Java 
> version there was code like this (but in reality more complex cases):
> for (...) {
>  if (cond2) { continue }
>  if (cond1) { continue }
>  // tens or hundreds of lines of code follows
> }
>
> At first I replaced it with
> for (... if !cond1 and !cond2) {...}
>
> which is actually more readable I think, but this has HORRIBLE 
> performance depending on the type of collection being filtered.
>
> So the solution was to write an if inside that block which covered the 
> whole block. This made for some quite deep nesting levels and for a 
> method with hundred lines or more that doesn't look so good. Of 
> course, the method probably could be broken up into smaller ones, but 
> I try to keep the port as similar to the Java code as possible (unless 
> the Scala way is clearly better).
>
Even here the Java way would be to move your hundreds of lines of guard 
conditions to a single function.

for(...){
    if(passesGuard(target)) doAction(target);
}

private boolean passesGuard(ThingOfInterest thing){
    if(cond1) return false;
    if(cond2) return false;
...
    return true;
}

I imagine scala would even more easily handle that approach with no need 
for a continue;

HTH
Brett Knights

headers

James Iry | 17 Oct 16:52

Re: The continue keyword

Given your example, you can write your own "continue" as long as you add elses

for (...) {
def continue = ()

if (cond1) continue
else if (cond2) continue
else hundreds of lines of code

}

Or the more direct

for (...) {
   if (cond1 || cond2 ) ()
   else hundreds of lines of code
}

On Thu, Oct 16, 2008 at 12:52 PM, Erkki Lindpere <erkki <at> lap.ee> wrote:

I would also say I'm very "imperative" but I have found examples where I missed both break and continue.

I'm porting the JBox2D physics engine to Scala and there are some long solver functions which iterate over various things. In the Java version there was code like this (but in reality more complex cases):
for (...) {
if (cond2) { continue }
if (cond1) { continue }
// tens or hundreds of lines of code follows
}

At first I replaced it with
for (... if !cond1 and !cond2) {...}

which is actually more readable I think, but this has HORRIBLE performance depending on the type of collection being filtered.

So the solution was to write an if inside that block which covered the whole block. This made for some quite deep nesting levels and for a method with hundred lines or more that doesn't look so good. Of course, the method probably could be broken up into smaller ones, but I try to keep the port as similar to the Java code as possible (unless the Scala way is clearly better).

Andrew Gaydenko wrote:
I'm very "imperative" man, or Java-infected, or - you say It is unbelievably, but I have not met a situation yet (during ~350-400KB of exercises) when this or that fragment can not be written absolutely readable (for my Java eyes) whithout 'break', 'continue' (and even 'return'!). Just use

headers

James Iry | 17 Oct 17:00

Re: The continue keyword

Or the even more direct
for (...) {
if (! (cond1 || cond2)) hundreds of lines of code
}

On Fri, Oct 17, 2008 at 7:52 AM, James Iry <jamesiry <at> gmail.com> wrote:

Given your example, you can write your own "continue" as long as you add elses

for (...) {
def continue = ()

if (cond1) continue
else if (cond2) continue
else hundreds of lines of code

}

Or the more direct

for (...) {
   if (cond1 || cond2 ) ()
   else hundreds of lines of code
}



On Thu, Oct 16, 2008 at 12:52 PM, Erkki Lindpere <erkki <at> lap.ee> wrote:
I would also say I'm very "imperative" but I have found examples where I missed both break and continue.

I'm porting the JBox2D physics engine to Scala and there are some long solver functions which iterate over various things. In the Java version there was code like this (but in reality more complex cases):
for (...) {
if (cond2) { continue }
if (cond1) { continue }
// tens or hundreds of lines of code follows
}

At first I replaced it with
for (... if !cond1 and !cond2) {...}

which is actually more readable I think, but this has HORRIBLE performance depending on the type of collection being filtered.

So the solution was to write an if inside that block which covered the whole block. This made for some quite deep nesting levels and for a method with hundred lines or more that doesn't look so good. Of course, the method probably could be broken up into smaller ones, but I try to keep the port as similar to the Java code as possible (unless the Scala way is clearly better).

Andrew Gaydenko wrote:
I'm very "imperative" man, or Java-infected, or - you say It is unbelievably, but I have not met a situation yet (during ~350-400KB of exercises) when this or that fragment can not be written absolutely readable (for my Java eyes) whithout 'break', 'continue' (and even 'return'!). Just use

headers

Judson, Ross | 17 Oct 17:27

RE: The continue keyword

Remember that a match will test in order and check guards, so:

for (item <- coll) item match {
  case _ if (cond1) => { }
  case _ if (cond2) => { }
  case n:Leaf => { ... }
  case b:Branch => { ... }
}

headers

Francesco Pasqualini | 18 Oct 05:32

Re: The continue keyword

On Wed, Oct 15, 2008 at 10:40 PM, Andrew Gaydenko <a <at> gaydenko.com> wrote:

Harshad,

I'm very "imperative" man, or Java-infected, or - you say It is
unbelievably, but I have not met a situation yet (during ~350-400KB of
exercises) when this or that fragment can not be written absolutely readable
(for my Java eyes) whithout 'break', 'continue' (and even 'return'!). Just use

- case matching,
- (!)short functions inside functions and
- tail recursion.

Hi,

It's sounds interesting, what you mean by " (!)short functions inside functions and"

Can you provide an example ?

Thanks

Francesco

headers

Andrew Gaydenko | 18 Oct 09:55

Re: The continue keyword

On Saturday 18 October 2008 07:32:26 Francesco Pasqualini wrote:
> On Wed, Oct 15, 2008 at 10:40 PM, Andrew Gaydenko <a <at> gaydenko.com> wrote:
> > Harshad,
> >
> > I'm very "imperative" man, or Java-infected, or - you say  It is
> > unbelievably, but I have not met a situation yet (during ~350-400KB of
> > exercises) when this or that fragment can not be written absolutely
> > readable
> > (for my Java eyes) whithout 'break', 'continue' (and even 'return'!).
> > Just use
> >
> > - case matching,
> > - (!)short functions inside functions and
> > - tail recursion.
>
> Hi,
> It's sounds interesting, what you mean  by " (!)short functions inside
> functions and"
>
> Can you provide an example ?

def f {
  def g = "123"
  println(g)
}

>
> Thanks
>
> Francesco