"continue/next" for "loop"

"continue/next" for "loop"

[Lutz Donnerhacke]

I might be out of coffee, but I do not find an elegant way to skip the rest
of a loop body for the current cycle other than using "goto".

with Ada.Text_IO;   use Ada.Text_IO;

procedure t is
begin
   for j in 2 .. 8 loop
      for i in 2 .. 8 loop
         if i mod j = 0 then  --  Assume complex statements here.
            goto next;        --  In my real case, it's another loop,
         end if;              --  which detects the end of current path inside.
         Put(i'Img);
         <<next>> null;
      end loop;
      New_Line;
   end loop;
end t;

Re: "continue/next" for "loop"

[Preben Randhol]

On 2003-11-03, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> I might be out of coffee, but I do not find an elegant way to skip the rest
> of a loop body for the current cycle other than using "goto".
>
> with Ada.Text_IO;   use Ada.Text_IO;
>
> procedure t is
> begin
>    for j in 2 .. 8 loop
>       for i in 2 .. 8 loop

>          if i mod j = 0 then  --  Assume complex statements here.
>             goto next;        --  In my real case, it's another loop,
>          end if;              --  which detects the end of current path inside.
>          Put(i'Img);
>          <<next>> null;

You cannot do:

         if i mod j != 0 then

            -- code
            Put(i'Img);

         end if;

? 

I don't quite understand you wuestion I think.


Preben
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: "continue/next" for "loop"

[Preben Randhol]

On 2003-11-03, Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
> On 2003-11-03, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
>> I might be out of coffee, but I do not find an elegant way to skip the rest
>> of a loop body for the current cycle other than using "goto".
>>
>> with Ada.Text_IO;   use Ada.Text_IO;
>>
>> procedure t is
>> begin
>>    for j in 2 .. 8 loop
>>       for i in 2 .. 8 loop
>
>>          if i mod j = 0 then  --  Assume complex statements here.
>>             goto next;        --  In my real case, it's another loop,
>>          end if;              --  which detects the end of current path inside.
>>          Put(i'Img);
>>          <<next>> null;
>
> You cannot do:
>
>          if i mod j != 0 then

ARG!       if i mod j /= 0 then

Been reading C sources :-(

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* Preben Randhol wrote:
> On 2003-11-03, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
>>    for j in 2 .. 8 loop
>>       for i in 2 .. 8 loop
>>          if i mod j = 0 then  --  Assume complex statements here.
>>             goto next;        --  In my real case, it's another loop,
>>          end if;              --  which detects the end of current path inside.
>>          Put(i'Img);
>>          <<next>> null;
> 
> You cannot do:
> 
>          if i mod j != 0 then

No. I don't know how to invert a complex loop.

Re: "continue/next" for "loop"

[Steve]

Not so elegant but:

 procedure t is
 begin
    for j in 2 .. 8 loop
       for i in 2 .. 8 loop
          inner_context:
            loop
              if i mod j = 0 then  --  Assume complex statements here.
                 exit inner_context;        --  In my real case, it's
another loop,
              end if;              --  which detects the end of current path
inside.
              Put(i'Img);
              exit inner_context;
            end loop inner_context;
       end loop;
       New_Line;
    end loop;
 end t;

which is basicly the same as the goto, but works for those with goto
allergies.

Steve
(The Duck)

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnbqccj0.m1.lutz@taranis.iks-jena.de...
> I might be out of coffee, but I do not find an elegant way to skip the
rest
> of a loop body for the current cycle other than using "goto".
>
> with Ada.Text_IO;   use Ada.Text_IO;
>
> procedure t is
> begin
>    for j in 2 .. 8 loop
>       for i in 2 .. 8 loop
>          if i mod j = 0 then  --  Assume complex statements here.
>             goto next;        --  In my real case, it's another loop,
>          end if;              --  which detects the end of current path
inside.
>          Put(i'Img);
>          <<next>> null;
>       end loop;
>       New_Line;
>    end loop;
> end t;
>

Re: "continue/next" for "loop"

[sk]

In an echo to my previous proposal for

raise <exception> when <boolean-condition>;

(which was generally rejected), how would Ada
users feel about a

goto <label> when <boolean-condition>;

statement ?

My position is again that of readability.



-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: "continue/next" for "loop"

[Stephen Leake]

sk <noname@myob.com> writes:

> In an echo to my previous proposal for
> 
> raise <exception> when <boolean-condition>;
> 
> (which was generally rejected), how would Ada
> users feel about a
> 
> goto <label> when <boolean-condition>;
> 
> statement ?

That's called "if"!

-- 
-- Stephe

Re: "continue/next" for "loop"

[sk]

Stephen Leake <Stephe.Leake@nasa.gov>:

 > That's called "if"!

Wow, I knew I should have read the LRM more thoroughly ...

Yes, my suggestion is totally irrelevent because Ada
contains an "if" statement. Thank you for the enlightenment.

-- 

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: "continue/next" for "loop"

[Stephen Leake]

Lutz Donnerhacke <lutz@iks-jena.de> writes:

> I might be out of coffee, but I do not find an elegant way to skip the rest
> of a loop body for the current cycle other than using "goto".
> 

Your loop, slightly modified:

procedure t is
begin
   for j in 2 .. 8 loop
      for i in 2 .. 8 loop
         if i mod j = 0 then
            null;
         else          
            Put(i'Img);
         end if;            
      end loop;
      New_Line;
   end loop;
end t;

If the "null" and "Put (i'Img)" are actually complex sequences of
statments, put them in a (local) procedure to make the top level
structure clear.

-- 
-- Stephe

RE: "continue/next" for "loop"

[amado.alves]

>> You cannot do:
>> 
>>          if i mod j != 0 then
>
> No. I don't know how to invert a complex loop.

What on Earth are you talking about? The two constructs

(1)  if I mod J = 0 then
        goto next;
     end if;
     Put (I'Img);
     <<next>> null;

(2)  if I mod J /= 0 then
        Put (I'Img);
     end if;

are clearly equivalent!

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* amado.alves wrote:
>> No. I don't know how to invert a complex loop.
> 
> What on Earth are you talking about? The two constructs
> 
> (1)  if I mod J = 0 then
>         goto next;
>      end if;
>      Put (I'Img);
>      <<next>> null;
> 
> (2)  if I mod J /= 0 then
>         Put (I'Img);
>      end if;
> 
> are clearly equivalent!

But both are the result of an oversimplification!

outer: loop
  inner: loop
    Complex_Actions_1;
    if First_Condition then
      Some_Justify_Actions;
      goto next_outer;
    end if;
    Complex_Actions_2;
    if Second_Condition then
      Some_Other_Justify_Actions;
      goto next_outer;
    end if;
    Complex_Actions_2;
  end loop inner;
  Complex_End_Statments;
  exit outer when Other_Condition;
  More_Statments;

  <<next_outer>> null;
end loop outer;

I'd like to find a more amazing version of this braindead goto.
Please do not assume, that I'm too stupid to invert a condition in a
simplified example. IT'S NOT HOMEWORK!

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* amado.alves wrote:
>> No. I don't know how to invert a complex loop.
> 
> What on Earth are you talking about? The two constructs
> 
> (1)  if I mod J = 0 then
>         goto next;
>      end if;
>      Put (I'Img);
>      <<next>> null;
> 
> (2)  if I mod J /= 0 then
>         Put (I'Img);
>      end if;
> 
> are clearly equivalent!

But both are the result of an oversimplification!

outer: loop
  inner: loop
    Complex_Actions_1;
    if First_Condition then
      Some_Justify_Actions;
      goto next_outer;
    end if;
    Complex_Actions_2;
    if Second_Condition then
      Some_Other_Justify_Actions;
      goto next_outer;
    end if;
    Complex_Actions_3;
  end loop inner;
  Complex_End_Statments;
  exit outer when Other_Condition;
  More_Statments;

  <<next_outer>> null;
end loop outer;

I'd like to find a more amazing version of this braindead goto.
Please do not assume, that I'm too stupid to invert a condition in a
simplified example. IT'S NOT HOMEWORK!

Re: "continue/next" for "loop"

[Peter Hermann]

assuming the number of keywords 69 constant,
we could imagine these:

goto loop [loopid];

or

exit [loopid] not [when ...];

for keywords look at
http://www.csv.ica.uni-stuttgart.de/homes/ph/adakurs/ak00090f.txt


-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: "continue/next" for "loop"

[Robert I. Eachus]

Peter Hermann wrote:

> assuming the number of keywords 69 constant,
> we could imagine these:

I actually think we are going to get one or two new reserved words in 
Ada 200X.

> goto loop [loopid];
> 
> or
> 
> exit [loopid] not [when ...];

But I think in the case of loops, there are clearly two specialized 
forms of goto that should be considered:

goto exit; -- exit innermost enclosing loop.
exit loop; -- alternative syntax. ;-)

and

goto end; -- skip to start of next loop iteration.
goto loop;
goto begin;

For the first case, I think that "exit loop" is probably the preferred 
notation.  It really is a goto in disguise, but one that need not be 
prohibited by those coding standards that prohibit gotos. ;-)

For the second, I am not sure whether "goto loop" or "goto end" is 
better.  In either case it really is a goto.  Other possibilities 
include "goto for" and "goto while," but this construct will IMHO often 
be used in loops with no for or while clauses.

Back to the earlier discussion about "with and use,"  I think that "exit 
loop" and "goto loop," if added to the language would clearly enhance 
readability and maintainability.



-- 
 
Robert I. Eachus

100% Ada, no bugs--the only way to create software.

Re: "continue/next" for "loop"

[(see below)]

On 3/11/03 16:49, in article GaOdnQutOP61GjuiRVn-hQ@comcast.com, "Robert I.
Eachus" <rieachus@comcast.net> wrote:

> But I think in the case of loops, there are clearly two specialized
> forms of goto that should be considered:
> 
> goto exit; -- exit innermost enclosing loop.
> exit loop; -- alternative syntax. ;-)
> 
> and
> 
> goto end; -- skip to start of next loop iteration.
> goto loop;
> goto begin;
... 
> For the second, I am not sure whether "goto loop" or "goto end" is
> better.  In either case it really is a goto.  Other possibilities
> include "goto for" and "goto while," but this construct will IMHO often
> be used in loops with no for or while clauses.

Does "goto loop" not imply jumping to a point *after* the for/while test, if
used in for/while loops? "goto end" clearly implies that the for/while test
is to be repeated.

> Back to the earlier discussion about "with and use,"  I think that "exit
> loop" and "goto loop," if added to the language would clearly enhance
> readability and maintainability.

Agreed, subject to the above.
-- 
Bill:Findlay chez Blue:Yonder dot:co:dot:uk (":" => "")

Re: "continue/next" for "loop"

[Jeffrey Carter]

Robert I. Eachus wrote:
> But I think in the case of loops, there are clearly two specialized 
> forms of goto that should be considered:
> 
> goto exit; -- exit innermost enclosing loop.
> exit loop; -- alternative syntax. ;-)

This already exists in Ada; it's syntax is

exit;

Without a loop name or when part, exit exits the innermost enclosing loop.

> and
> 
> goto end; -- skip to start of next loop iteration.
> goto loop;
> goto begin;

This doesn't exist. Ichbiah and others were aware of "continue" in C but 
chose not to include it in Ada 83. Did they have a good reason? Is the 
Ada-83 Rationale available on line anywhere?

The problem with this discussion is that we don't know what the OP is 
trying to do; we only know how he is trying to do it, sort of. As 
pointed out elsewhere, the goto's could be converted to "exit Inner;" 
and the statements between "end Inner;" and "end Outer;" removed, with 
no change in behavior, so we don't really even know how the OP is trying 
to do whatever he is trying to do. If we knew what he was trying to 
achieve, rather than how he was trying to do it, we might be able to 
propose an alternative approach that would avoid his problem.

Assuming some way to exit Inner and execute the statements between the 
end of Inner and the end of Outer, we have seen a number of ways to 
achieve this: goto statements, a Boolean flag, and exceptions. Another 
way is to use a dummy loop and exit it:

Outer : loop
    Dummy : loop
       Inner : loop
          ...
          if First then
             ...
             exit Dummy;
          end if;
          ...
          if Second then
             ...
             exit Dummy;
          end if;
          ...
          exit Inner when Third;
       end Inner;
       ...
       exit Dummy;
    end Dummy;
end Outer;

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* Jeffrey Carter wrote:
> The problem with this discussion is that we don't know what the OP is
> trying to do; we only know how he is trying to do it, sort of.

What: I'm writing teaching programs for a security class.
How : I'm writing readable programs for a security class.

> As pointed out elsewhere, the goto's could be converted to "exit Inner;"
> and the statements between "end Inner;" and "end Outer;" removed, with no
> change in behavior, so we don't really even know how the OP is trying to
> do whatever he is trying to do. If we knew what he was trying to achieve,
> rather than how he was trying to do it, we might be able to propose an
> alternative approach that would avoid his problem.

Sorry, that I does not include the source code of the upcomming exercise now.
I only noticed a missing language expressivity and asked about my dumbness.

> Assuming some way to exit Inner and execute the statements between the 
> end of Inner and the end of Outer, we have seen a number of ways to 
> achieve this: goto statements, a Boolean flag, and exceptions. Another 
> way is to use a dummy loop and exit it:

All those ways are possible, but they lose readbility.

Re: "continue/next" for "loop"

[Robert I. Eachus]

Jeffrey Carter wrote:

>> goto exit; -- exit innermost enclosing loop.
>> exit loop; -- alternative syntax. ;-)
> 
> 
> This already exists in Ada; it's syntax is
> 
> exit;
> 
> Without a loop name or when part, exit exits the innermost enclosing loop.

Correct.  I often use "exit when."  Actually for the type of cases 
discussed here, I often write the loop as an inlined procedure or 
function and use a return statement for premature loop termination. (As 
an example, walking an AVL tree looking for a particular key.  The 
return takes care of all the complex nesting issues that can occur.)

The goto exit was proposed as "syntactic sugar," since I often see 
programmers using gotos where exit would do the job. I thought "exit 
loop" was rubbing the sarcasm in even with the smiley. I have too many 
times been asked how can I exit a loop.  So I thought it was obvious I 
was being sarcastic.  (Maybe I should have said:

exit [loop_name]; -- alternative syntax. ;-)

Incidently, I the problem which results in exit statements being 
overlooked is classes that teach for loops, then while loops and maybe 
eventually get around to:

loop
   ...
   exit when Done;
   ...
end loop;

If you teach students about the general purpose loop first, then add for 
and while loops as special cases, maybe students will remember. I have 
no problem.  In the first Ada compiler I worked on, while loops were 
parsed exactly as if they said "loop exit when not <expression>; 
<sequence of statements> end loop;"  No reason to generate extra work 
for semantic analysis when we could eliminate some constructs in the 
parser by translating them into token streams with identical meanings.

As for the horrible example that started this thread, I have often had 
to deal with this type of twisted loop in parsing.  Often the best 
solution is instead of using two for loops use one plain loop, and make 
incrementing the loop variables explicit.  Sometimes that gets too heavy 
and you really do have to go to named states with gotos.

> procedure t is
> begin
>    for j in 2 .. 8 loop
>       for i in 2 .. 8 loop
>          if i mod j = 0 then  --  Assume complex statements here.
>             goto next;        --  In my real case, it's another loop,
>          end if;              --  which detects the end of current path inside.
>          Put(i'Img);
>          <<next>> null;
>       end loop;
>       New_Line;
>    end loop;
> end t;


procedure t is
begin
    for j in 2 .. 8 loop
       for i in 2 .. 8 loop
          if i mod j = 0 then  --  Assume complex statements here.
             exit;
          else
             Put(i'Img);
          end if;
       end loop;
       New_Line;
    end loop;
end t;

Which in part was why I thought this was another case of "Help! I'm 
stuck inside a loop and can't get out."

-- 

                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.

Re: "continue/next" for "loop"

[James Rogers]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in 
news:slrnbqckoa.m1.lutz@taranis.iks-jena.de:

> But both are the result of an oversimplification!
> 
> outer: loop
>   inner: loop
>     Complex_Actions_1;
>     if First_Condition then
>       Some_Justify_Actions;
>       goto next_outer;
>     end if;
>     Complex_Actions_2;
>     if Second_Condition then
>       Some_Other_Justify_Actions;
>       goto next_outer;
>     end if;
>     Complex_Actions_3;
>   end loop inner;
>   Complex_End_Statments;
>   exit outer when Other_Condition;
>   More_Statments;
> 
>   <<next_outer>> null;
> end loop outer;

declare
   Outer_Continue : boolean;
begin
outer: loop
   inner : loop
      Complex_Actions_1;
      if First_Condition then
         Some_Justify_Actions;
         Outer_Continue := false;
         exit inner;
      end if;
      Complex_Actions_2;
      if Second_Condition then
         Some_Other_Justify_Actions;
         Outer_Continue := false;
         exit inner;
      end if;
      Outer_Continue := true;
      Complex_Actions_3;
   end loop inner;
   if Outer_Continue then
      Complex_End_Statements;
      exit outer when Other_Condition;
   end if;
end loop outer;


Jim Rogers
      

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* James Rogers wrote:
> Lutz Donnerhacke <lutz@iks-jena.de> wrote in 
>>     if First_Condition then
>>       Some_Justify_Actions;
>>       goto next_outer;
[...]
>>   <<next_outer>> null;
>> end loop outer;
> 
> declare
>    Outer_Continue : boolean;
> begin
> outer: loop
>    inner : loop
>       Complex_Actions_1;
>       if First_Condition then
>          Some_Justify_Actions;
>          Outer_Continue := false;
>          exit inner;
>       end if;
>       Complex_Actions_2;
>       if Second_Condition then
>          Some_Other_Justify_Actions;
>          Outer_Continue := false;
>          exit inner;
>       end if;
>       Outer_Continue := true;
>       Complex_Actions_3;
>    end loop inner;
>    if Outer_Continue then
>       Complex_End_Statements;
>       exit outer when Other_Condition;
>    end if;
> end loop outer;

Thanx, that's as bad.

Re: "continue/next" for "loop"

[Dmitry A. Kazakov]

On Mon, 3 Nov 2003 13:07:22 +0000 (UTC), Lutz Donnerhacke
<lutz@iks-jena.de> wrote:

>* amado.alves wrote:
>>> No. I don't know how to invert a complex loop.
>> 
>> What on Earth are you talking about? The two constructs
>> 
>> (1)  if I mod J = 0 then
>>         goto next;
>>      end if;
>>      Put (I'Img);
>>      <<next>> null;
>> 
>> (2)  if I mod J /= 0 then
>>         Put (I'Img);
>>      end if;
>> 
>> are clearly equivalent!
>
>But both are the result of an oversimplification!
>
>outer: loop
>  inner: loop
>    Complex_Actions_1;
>    if First_Condition then
>      Some_Justify_Actions;
>      goto next_outer;
>    end if;
>    Complex_Actions_2;
>    if Second_Condition then
>      Some_Other_Justify_Actions;
>      goto next_outer;
>    end if;
>    Complex_Actions_3;
>  end loop inner;
>  Complex_End_Statments;
>  exit outer when Other_Condition;
>  More_Statments;
>
>  <<next_outer>> null;
>end loop outer;
>
>I'd like to find a more amazing version of this braindead goto.
>Please do not assume, that I'm too stupid to invert a condition in a
>simplified example. IT'S NOT HOMEWORK!

It looks that you are implementing a kind of state machine. If so
then, it is a rare case where labels are more natural than higher
level constructs.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: "continue/next" for "loop"

[Ole-Hjalmar Kristensen]

>>>>> "LD" == Lutz Donnerhacke <lutz@iks-jena.de> writes:

    LD> * amado.alves wrote:
    >>> No. I don't know how to invert a complex loop.
    >> 
    >> What on Earth are you talking about? The two constructs
    >> 
    >> (1)  if I mod J = 0 then
    >> goto next;
    >> end if;
    >> Put (I'Img);
    >> <<next>> null;
    >> 
    >> (2)  if I mod J /= 0 then
    >> Put (I'Img);
    >> end if;
    >> 
    >> are clearly equivalent!

    LD> But both are the result of an oversimplification!

    LD> outer: loop
    LD>   inner: loop
    LD>     Complex_Actions_1;
    LD>     if First_Condition then
    LD>       Some_Justify_Actions;
    LD>       goto next_outer;
    LD>     end if;
    LD>     Complex_Actions_2;
    LD>     if Second_Condition then
    LD>       Some_Other_Justify_Actions;
    LD>       goto next_outer;
    LD>     end if;
    LD>     Complex_Actions_3;
    LD>   end loop inner;
    LD>   Complex_End_Statments;
    LD>   exit outer when Other_Condition;
    LD>   More_Statments;

    LD>   <<next_outer>> null;
    LD> end loop outer;

    LD> I'd like to find a more amazing version of this braindead goto.
    LD> Please do not assume, that I'm too stupid to invert a condition in a
    LD> simplified example. IT'S NOT HOMEWORK!

It seems you are looking for a multi-level "continue" statement :-)
You need to somehow store the results of your tests if you want to
avoid the goto, because this information is used outside the scope of
the inner loop. A boolean should suffice, but is the code any more
readable?

   outer: loop
     declare 
        execute_outer_statements : boolean := false;
     begin
       inner: loop
         Complex_Actions_1;
         if First_Condition then
           Some_Justify_Actions;
         else
           Complex_Actions_2;
           if Second_Condition then
             Some_Other_Justify_Actions;
           else        
             Complex_Actions_3;
             execute_statements := true;
           end if;
         end if;
       end loop inner;
       if execute_outer_statements then
         Complex_End_Statments;
         exit outer when Other_Condition;
         More_Statments;
       end if;
     end;
   end loop outer;

You could of course make your inner loop an inline procedure returning
a boolean to separate the logic of the inner and outer loops more clearly:

   outer: loop
     declare 
       procedure inner_loop(doit : out boolean) is
       begin 
         Complex_Actions_1;
         if First_Condition then
           Some_Justify_Actions;
           doit := false;
         else
           Complex_Actions_2;
           if Second_Condition then
             Some_Other_Justify_Actions;
             doit := false;
           else        
             Complex_Actions_3;
             doit := true;
           end if;
         end if;
       end inner_loop;
       pragma inline(inner_loop);
       
       execute_outer_statements : boolean;
     begin
       inner_loop(execute_outer_statements);
       if execute_outer_statements then
         Complex_End_Statments;
         exit outer when Other_Condition;
         More_Statments;
       end if;
     end;
   end loop outer;

After looking at these alternatives, I would probably stick with the goto.

-- 
Strange attractors stole my wife

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* Ole-Hjalmar Kristensen wrote:
> It seems you are looking for a multi-level "continue" statement :-)

Yep. I wonder that it is missing.

> You need to somehow store the results of your tests if you want to
> avoid the goto, because this information is used outside the scope of
> the inner loop. A boolean should suffice, but is the code any more
> readable?

No, the code will blow up.

> After looking at these alternatives, I would probably stick with the goto.

Yes. There is no "continue loop_name" like "exit loop_name". May I suggest ...

Re: "continue/next" for "loop"

[Stefan Lucks]

Lutz,

as far as I can see, your program fragment never terminates: There is no
"exit inner" in your code, and thus the"exit outer" is dead code.  Am I
missing something?

On Mon, 3 Nov 2003, Lutz Donnerhacke wrote:

> outer: loop
>   inner: loop
>     Complex_Actions_1;
>     if First_Condition then
>       Some_Justify_Actions;
>       goto next_outer;
>     end if;
>     Complex_Actions_2;
>     if Second_Condition then
>       Some_Other_Justify_Actions;
>       goto next_outer;
>     end if;
>     Complex_Actions_3;
>   end loop inner;

-- The next three lines seem to be DEAD CODE:

>   Complex_End_Statments;
>   exit outer when Other_Condition;
>   More_Statments;

>   <<next_outer>> null;
> end loop outer;


If you really want to describe a nonterminating loop, you could delete the
dead code lines and replace both goto statements by "exit inner". My guess
is, this is not what you are looking for. Could this be due to another
oversimplification?

Stefan


-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  smell  of  Cryptanalysis  in  the  morning!  ------

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* Stefan Lucks wrote:
> as far as I can see, your program fragment never terminates: There is no
> "exit inner" in your code, and thus the"exit outer" is dead code.  Am I
> missing something?

Yes. It's a structural example.

Re: "continue/next" for "loop"

[Charles Lindsey]

In <slrnbqckoa.m1.lutz@taranis.iks-jena.de> Lutz Donnerhacke <lutz@iks-jena.de> writes:

>But both are the result of an oversimplification!

>outer: loop
>  inner: loop
>    Complex_Actions_1;
>    if First_Condition then
>      Some_Justify_Actions;
>      goto next_outer;
>    end if;
>    Complex_Actions_2;
>    if Second_Condition then
>      Some_Other_Justify_Actions;
>      goto next_outer;
>    end if;
>    Complex_Actions_3;
>  end loop inner;
>  Complex_End_Statments;
>  exit outer when Other_Condition;
>  More_Statments;

Yes, that is fine, and it is well-structured. But it is still not the most
general case.

Here is what I used to teach. The original idea came from Eberhard Wegner,
and if you recognize who he was (or who I am), you will realize that this
argument has been going on for a very long time (see my paper in SIGPLAN
Notices for November 1977). There have been no new arguments added since
then that have not been repeated ad nauseam ever since (least of all in
this latest thread).

1. You can regard a well-structured program as a set of nested boxes. Or of
nested levels of indentation as in Lutz's example above.

2. Those boxes are not just the bodies of loops. They include the THEN and
ELSE part of conditionals, the individual alternatives of CASEs, and even
BEGIN...END blocks introduced just for the hell of it.

3. There are just TWO acceptable forms of GOTO:

   3a. The REPEATER

   This is a jump from the inside of one box to the START of some
   enclosing box (cutting through as many intermediate boxes as you wish).

   3b. The COMPLETER

   This is a jump from the inside of one box to the END of some
   enclosing box (cutting through as many intermediate boxes as you wish).

NOTE 1: The words "START" (for the completer) and "END" (for the repeater).
Another way of saying the same thing is that the only acceptable places
for a LABEL are at the START of a new level of indentation, or ar the END
of an old level of indentation. 

NOTE 2: It doesn't just apply to loops.

NOTE 3: You may be able to restructure the program (add BEGIN...END
blocks, move stuff outside of blocks, etc) so as to achieve the effect,
but there exist some programs which cannot be restrutured that way, and
which will force you to jump INTO a box from outside. Those are the
unstructured "spaghetti" programs, which should indeed be "considered
harmful".

NOTE 4: Of course, this shows that GOTOs and LABELS were the wrong
language tools to have invented in the first place. Various languages seek
to remedy this by inventing constructs such as EXIT, or CONTINUE, or
EXCEPTIONS; but the mistake most of them make is to restrict these
constructs only to LOOPS, or only to exit through one level of nesting.


Essentially, the Repeater means "I have got myself into this deeply nested
mess where I cannot proceed further; I just want to START OVER".

The Completer means "I have got myself into this deeply nested
mess where I cannot proceed further; I just want to BAIL OUT".

It turns out, in practice, that the Completer is the most useful tool. The
effect of the Repeater can as easily be obtained in most cases by a
conventional WHILE loop.

And yes, even Spaghetti programs can be made to look structured by
inventing a sufficiently large number of boolean variables. That too has
been known for the last 25 years, so do not bother repeating it. It DOES
NOT make a program any clearer, as opposed to well-structured jumps as
above. It just assuages the consciences of those who believe the myth that
ALL GOTOs are harmful, which nobody (no, not even the late lamented
Edsger) ever said they were.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* Charles Lindsey wrote:
> Yes, that is fine, and it is well-structured. But it is still not the most
> general case.

Of course. BTW, I found a transformation in the problem space which results
in a single if_statement in the nested loop.

> 3. There are just TWO acceptable forms of GOTO:
> 
>    3a. The REPEATER
> 
>    This is a jump from the inside of one box to the START of some
>    enclosing box (cutting through as many intermediate boxes as you wish).
> 
>    3b. The COMPLETER
> 
>    This is a jump from the inside of one box to the END of some
>    enclosing box (cutting through as many intermediate boxes as you wish).

Ada provides exit_statement for the completer, but misses an equivalent for
the repeater. Bad.

Re: "continue/next" for "loop"

[Martin Dowie]

"Charles Lindsey" <chl@clerew.man.ac.uk> wrote in message news:<HnvK4B.6Mu@clerew.man.ac.uk>...

> 1. You can regard a well-structured program as a set of nested boxes. Or of
> nested levels of indentation as in Lutz's example above.
[snip]
> And yes, even Spaghetti programs can be made to look structured by
> inventing a sufficiently large number of boolean variables. That too has
> been known for the last 25 years, so do not bother repeating it. It DOES
> NOT make a program any clearer, as opposed to well-structured jumps as
> above. It just assuages the consciences of those who believe the myth that
> ALL GOTOs are harmful, which nobody (no, not even the late lamented
> Edsger) ever said they were.

From my very dusty memory, this sounds a lot like the principles used in
Jackson Structured Programming (JSP), esp, the bit about everything
being nested boxes... the controlled jumps sound a bit like the 'backtracking'
technique and the abhorance of 'programmer invented flags' would warm
the heart of my old JSP/COBOL lecturer no end :-)

Are these philosophies related?

Re: "continue/next" for "loop"

[Charles Lindsey]

In <af783afe.0311060148.19e29271@posting.google.com> martin.dowie@btopenworld.com (Martin Dowie) writes:

>From my very dusty memory, this sounds a lot like the principles used in
>Jackson Structured Programming (JSP), esp, the bit about everything
>being nested boxes... the controlled jumps sound a bit like the 'backtracking'
>technique and the abhorance of 'programmer invented flags' would warm
>the heart of my old JSP/COBOL lecturer no end :-)

I think "nested boxes" is the essential feature of _any_ structured
programming, including Jackson's. Yes, it is a long time time I knew what
Jackson's system was all about, but I do recall that it seemed to be a bit
overhyped at the time.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Re: "continue/next" for "loop"

[Martin Dowie]

"Charles Lindsey" <chl@clerew.man.ac.uk> wrote in message
news:HnzLEA.LMB@clerew.man.ac.uk...
> In <af783afe.0311060148.19e29271@posting.google.com>
martin.dowie@btopenworld.com (Martin Dowie) writes:
>
> I think "nested boxes" is the essential feature of _any_ structured
> programming, including Jackson's. Yes, it is a long time time I knew what
> Jackson's system was all about, but I do recall that it seemed to be a bit
> overhyped at the time.

I still bear some of his teaching in mind... like basing programs on the
structure
of the data it manipulates - for file processing programs at any rate.

The best hype I heard was that "Abbey National" (a UK bank) had found
that since moving to JSP, that testing was no longer cost effective!

And to be fair, I think it did 'raise the game' for 'below par' programmers.

-- Martin

Re: "continue/next" for "loop"

[Jeffrey Carter]

Charles Lindsey wrote:

> I think "nested boxes" is the essential feature of _any_ structured
> programming, including Jackson's. Yes, it is a long time time I knew what
> Jackson's system was all about, but I do recall that it seemed to be a bit
> overhyped at the time.

No matter what you think about JSP, it's better than the method used by 
98% of SW developers: sit down and start coding.

-- 
Jeff Carter
"C's solution to this [variable-sized arrays] has real problems,
and people who are complaining about safety definitely have a point."
Dennis Ritchie
25

Re: "continue/next" for "loop"

[Jim Rogers]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbqckoa.m1.lutz@taranis.iks-jena.de>...
> But both are the result of an oversimplification!
> 
> outer: loop
>   inner: loop
>     Complex_Actions_1;
>     if First_Condition then
>       Some_Justify_Actions;
>       goto next_outer;
>     end if;
>     Complex_Actions_2;
>     if Second_Condition then
>       Some_Other_Justify_Actions;
>       goto next_outer;
>     end if;
>     Complex_Actions_3;
>   end loop inner;
>   Complex_End_Statments;
>   exit outer when Other_Condition;
>   More_Statments;
> 
>   <<next_outer>> null;
> end loop outer;
> 
> I'd like to find a more amazing version of this braindead goto.
> Please do not assume, that I'm too stupid to invert a condition in a
> simplified example. IT'S NOT HOMEWORK!

Upon further consideration of your example above I see that you could
look upon the early break out of the inner loop as an exceptional condition,
or as a set of exceptional conditions. Given this, another solution is
the use of exceptions.

 First_Condition_Exception : Exception;
 Second_Condition_Exception : Exception;

 outer: loop
   begin
     inner: loop
       Complex_Actions_1;
       if First_Condition then
         raise First_Condition_Exception;
       end if;
       Complex_Actions_2;
       if Second_Condition then
         raise Second_Condition_Exception;
       end if;
       Complex_Actions_3;
     end loop inner;
     Complex_End_Statments;
     exit outer when Other_Condition;
     More_Statments;
 
   Exception
      when First_Condition_Exception =>
         Some_Justify_Actions;
      when Second_Condition_Exception =>
         Some_Other_Justify_Actions;
   end;
 end loop outer;

Jim Rogers

Re: "continue/next" for "loop"

[christoph.grein]

Really, Lutz, I do not see why you by any force would like a solution without 
goto. It's the most appropriate solution in this case!

The goto solution is better understandable than the boolean condition one. And 
it's simpler. Has anyone noticed that More_Statments are missing in the non-goto 
solution?

Why is the goto braindead? Your coding standards forbit it? I hate those silly 
standards which forbid the most natural solution.

> Lutz Donnerhacke <lutz@iks-jena.de> wrote in 
> news:slrnbqckoa.m1.lutz@taranis.iks-jena.de:
> 
> > But both are the result of an oversimplification!
> > 
> > outer: loop
> >   inner: loop
> >     Complex_Actions_1;
> >     if First_Condition then
> >       Some_Justify_Actions;
> >       goto next_outer;
> >     end if;
> >     Complex_Actions_2;
> >     if Second_Condition then
> >       Some_Other_Justify_Actions;
> >       goto next_outer;
> >     end if;
> >     Complex_Actions_3;
> >   end loop inner;
> >   Complex_End_Statments;
> >   exit outer when Other_Condition;
> >   More_Statments;
> > 
> >   <<next_outer>> null;
> > end loop outer;
> 
> declare
>    Outer_Continue : boolean;
> begin
> outer: loop
>    inner : loop
>       Complex_Actions_1;
>       if First_Condition then
>          Some_Justify_Actions;
>          Outer_Continue := false;
>          exit inner;
>       end if;
>       Complex_Actions_2;
>       if Second_Condition then
>          Some_Other_Justify_Actions;
>          Outer_Continue := false;
>          exit inner;
>       end if;
>       Outer_Continue := true;
>       Complex_Actions_3;
>    end loop inner;
>    if Outer_Continue then
>       Complex_End_Statements;
>       exit outer when Other_Condition;
>    end if;
> end loop outer;
> 
> 
> Jim Rogers

Re: "continue/next" for "loop"

[Preben Randhol]

On 2003-11-03, christoph.grein@eurocopter.com <christoph.grein@eurocopter.com> wrote:

> Really, Lutz, I do not see why you by any force would like a solution
> without goto. It's the most appropriate solution in this case!
>
> The goto solution is better understandable than the boolean condition
> one. And it's simpler. Has anyone noticed that More_Statments are
> missing in the non-goto solution?
>
> Why is the goto braindead? Your coding standards forbit it? I hate
> those silly standards which forbid the most natural solution.

Links on this:  (Ada, goto and state machine)

<URL: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&th=2e40522bae321cd3&seekm=yeung-ya02408000R0907970151100001%40news.apple.com#link1>

<URL: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&rnum=1&thl=0,1962504160,1962489216,1962271017,1962126670,1961964531,1961870021,1961870001,1961823517,1961823513,1961823498,1961752985&seekm=3m0nv5%2467l%40theopolis.orl.mmc.com#link1>

<URL: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&rnum=1&thl=0,1859794614,1859987362,1859947797,1859825550,1859773407,1858986694,1859689585,1858790444,1858650901,1857956692,1857898236&seekm=dewar.866134855%40merv#link1>

<URL: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&th=6ab044fa0a1401a2&seekm=dewar.866287533%40merv#link1>

Preben
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* Preben Randhol wrote:
> Links on this:  (Ada, goto and state machine)

It's not a state machine. It's a "parser" which determine the end of the
current iteration processing at a much deeper level.

Re: "continue/next" for "loop"

[Dmitry A. Kazakov]

On Mon, 3 Nov 2003 15:01:52 +0000 (UTC), Lutz Donnerhacke
<lutz@iks-jena.de> wrote:

>* Preben Randhol wrote:
>> Links on this:  (Ada, goto and state machine)
>
>It's not a state machine. It's a "parser" which determine the end of the
>current iteration processing at a much deeper level.

A "parser" isn't that different from FSM. So far your FSM or
whatsoever needs no stack(s) to wind up upon state changing, goto's
are just fine.

Otherwise it becomes a nigthmare, no matter how you are going to do
it! So stop feeling guilty, and use gotos! (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: "continue/next" for "loop"

[Chad R. Meiners]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:bqrcqvscteqbh6s5ta7e1ntqnb9p84km1s@4ax.com...
> On Mon, 3 Nov 2003 15:01:52 +0000 (UTC), Lutz Donnerhacke
> <lutz@iks-jena.de> wrote:
>
> >It's not a state machine. It's a "parser" which determine the end of the
> >current iteration processing at a much deeper level.
>
> A "parser" isn't that different from FSM. So far your FSM or
> whatsoever needs no stack(s) to wind up upon state changing, goto's
> are just fine.
>
> Otherwise it becomes a nigthmare, no matter how you are going to do
> it! So stop feeling guilty, and use gotos! (:-))

Agreed, when writing parsers and FSM, I use goto's when necessary.  It's
much better than if constructs and booleans.

-CRM

Re: "continue/next" for "loop"

[Preben Randhol]

On 2003-11-03, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> * Preben Randhol wrote:
>> Links on this:  (Ada, goto and state machine)
>
> It's not a state machine. It's a "parser" which determine the end of the
> current iteration processing at a much deeper level.


Only one of the threads had to do with state machine :-)

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: "continue/next" for "loop"

[Georg Bauhaus]

Lutz Donnerhacke <lutz@iks-jena.de> wrote:
: * Preben Randhol wrote:
:> Links on this:  (Ada, goto and state machine)
: 
: It's not a state machine. It's a "parser" which determine the end of the
: current iteration processing at a much deeper level.

Does it have to be at that low language level, then?
Why not carry abstraction further, adjust data definitions,
so that the spaghetti become more manageable? :-)
"Continue that_loop" denotes something, after all.

In addition,  "Continue that_loop" might have other natural
connotations for other people, for example Perl programmers
might feel that a bare jump to some loop's start is inferior
to something like this:

  loop
      ...
      if condition then
          goto loop_end;
      end if;
      ...
    <<loop_end>>
      common_cleanup;
  end loop;

Or consult Knuth, on  Structured Programming with go to Statements.
http://doi.acm.org/10.1145/356635.356640


Georg

Re: "continue/next" for "loop"

[Lutz Donnerhacke]

* christoph.grein@eurocopter.com wrote:
> Really, Lutz, I do not see why you by any force would like a solution
> without goto. It's the most appropriate solution in this case!

No. "continue [loop_name]" is the appropriate solution. It does express the
intent of the programmer.

> The goto solution is better understandable than the boolean condition
> one. And it's simpler. Has anyone noticed that More_Statments are missing
> in the non-goto solution?

The "goto label" version is a workaround to a missing language expressivity.
"continue [loop_name]" like "exit [loop_name]" would be clearer.

Of course, you never need any of them. "if then end if" and "goto" will do
the job anyway.

> Why is the goto braindead? Your coding standards forbit it? I hate those
> silly standards which forbid the most natural solution.

The "natural solution" is to command the compiler to skip over to the next
iteration.

RE: "continue/next" for "loop"

[amado.alves]

Sometimes I use exceptions:

outer: loop
 DECLARE
  DONE : EXCEPTION;
 BEGIN
  inner: loop
    Complex_Actions_1;
    if First_Condition then
      Some_Justify_Actions;
      RAISE DONE; --goto next_outer;
    end if;
    Complex_Actions_2;
    if Second_Condition then
      Some_Other_Justify_Actions;
      RAISE DONE; --goto next_outer;
    end if;
    Complex_Actions_3;
  end loop inner;
  Complex_End_Statments;
  exit outer when Other_Condition;
  More_Statments;
  --<<next_outer>> null;
 EXCEPTION
  WHEN DONE => NULL;
 END;
end loop outer;

RE: "continue/next" for "loop"

[amado.alves]

"Sometimes I use exceptions..."

I remember some people are against using exceptions for control flow. I think this even appears in some coding standards.

So, as other have said, the goto might be appropriate.

Yet another way is to structure the code more, i.e. put the crucial sequences of statements inside (local) procedures, and then call the procedures at the appropriate points.

Of course you may have to parametrize the procedures to pass the values of the loop control variables.

Come to think of it, this is probably how I do it most of the times. I seem to remember having really long procedure names...

Re: "continue/next" for "loop"

[Dmytry Lavrov]

I have example where gotos are natural:
kind of bresentham line drawing routine(coded in assembler)
2 not nested loops that shares some operators,and it was natural to
enter loop different ways depend to initial situation.

Something like

initially_find_where_to_enter;
Loop1 start

loop2 start
shared_statements
loop1end

loop2end

And also parsers generated by lex or maybe other tools are using gotos
because it's far more natural.

Regards,

Dmytry Lavrov.

Re: "continue/next" for "loop"

[Gautier Write-only]

# "Sometimes I use exceptions..."

Reworded: "I use exceptions, but exceptionally...".
Sorry, I couldn't resist...
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!