1. Exiting multiple loop constructs
We've talked about labeled loops and a bit about existing loop constructs,
exiting loops, etc... but I do not think we came to any conclusive decision. Here
is a summary of different methods of exiting multiple loops:
integer in_top
in_top = 1
while in_top do
for i = 1 to 10 do
if i = 3 then
in_top = 0
exit
end if
end for
end while
This will work fine unless you have processing *under* the nested loop, then you
must provide an extra condition check (which is in a loop and is executed each
iteration):
integer in_top
in_top = 1
while in_top do
for i = 1 to 10 do
if i = 3 then
in_top = 0
exit
end if
end for
if in_top = 0 then
exit
end if
-- do more processing here
end while
NOTE: The above two methods compound in complexity with each nested loop you
add. However, in real life, I'm not sure if I have ever programmed a loop that is
3 deep.
This method uses optional numeric methods to exit and continue keywords:
while 1 do
for i = 1 to 10 do
if i = 3 then exit 2 -- end if
end for
end while
Notice "exit 2". That means exit 2 loops.
The final method is labeled loops, in which I will make a slightly more advanced
example.
while 1 label top do
for i = 1 to 10 label mid do
for j = 1 to 10 label bottom do
-- exit current loop "to" the top loop
if j = 2 then exit top end if
-- exit all loops (in this function)
if j = 5 then exit all end if
end for
end for
end while
So. Is one clearer than another? I do not know. Should any syntax change to
support exiting multiple loops? I am not sure, the benefit is you can remove
multiple checks making code easier to write and better performing.
So, what do you think? Are there other ways that I missed? What should be done?
--
Jeremy Cowgar
http://jeremy.cowgar.com
2. Re: Exiting multiple loop constructs
Jeremy Cowgar wrote:
>
> We've talked about labeled loops and a bit about existing loop constructs,
> exiting
> loops, etc... but I do not think we came to any conclusive decision. Here is
> a summary of different methods of exiting multiple loops:
>
> }}}
<eucode>
> integer in_top
> in_top = 1
>
> while in_top do
> for i = 1 to 10 do
> if i = 3 then
> in_top = 0
> exit
> end if
> end for
> end while
> </eucode>
{{{
>
> This will work fine unless you have processing *under* the nested loop, then
> you must provide an extra condition check (which is in a loop and is executed
> each iteration):
>
> }}}
<eucode>
> integer in_top
> in_top = 1
>
> while in_top do
> for i = 1 to 10 do
> if i = 3 then
> in_top = 0
> exit
> end if
> end for
> if in_top = 0 then
> exit
> end if
> -- do more processing here
> end while
> </eucode>
{{{
>
> NOTE: The above two methods compound in complexity with each nested loop you
> add. However, in real life, I'm not sure if I have ever programmed a loop that
> is 3 deep.
>
> This method uses optional numeric methods to exit and continue keywords:
>
> }}}
<eucode>
> while 1 do
> for i = 1 to 10 do
> if i = 3 then exit 2 -- end if
> end for
> end while
> </eucode>
{{{
>
> Notice "exit 2". That means exit 2 loops.
>
> The final method is labeled loops, in which I will make a slightly more
> advanced
> example.
>
> }}}
<eucode>
> while 1 label top do
> for i = 1 to 10 label mid do
> for j = 1 to 10 label bottom do
> -- exit current loop "to" the top loop
> if j = 2 then exit top end if
>
> -- exit all loops (in this function)
> if j = 5 then exit all end if
> end for
> end for
> end while
> </eucode>
{{{
>
>
> So. Is one clearer than another? I do not know. Should any syntax change to
> support exiting multiple loops? I am not sure, the benefit is you can remove
> multiple checks making code easier to write and better performing.
>
> So, what do you think? Are there other ways that I missed? What should be
> done?
I prefer :
while 1 do -- label top
for i = 1 to 10 do -- label mid
for j = 1 to 10 do -- label bottom
-- exit current loop "to" the top loop
if j = 2 then exit top end if
-- exit all loops (in this function)
if j = 5 then exit all end if
end for
end for
end while
or
while 1 do
for i = 1 to 10 do
for j = 1 to 10 do
-- exit current loop "to" the top loop
if j = 2 then goto whereiwanto end if
-- exit all loops (in this function)
if j = 5 then goto whereiwantonow end if
end for
end for
end while
Kat
3. Re: Exiting multiple loop constructs
My only real concern is the placement of the "label" statement. Not sure where
it should go to be most clear.
I don't like the "all" option, you should know the label of the highest level
you are exiting. No need for a predefined label, IMO.
I'm not sure what kinds of stack cleanup/unwinding would need to be done in
order to prevent memory/resource leaks and/or fill up the interpreter's stack
with data from exited loops.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
4. Re: Exiting multiple loop constructs
Jeremy Cowgar wrote:
>
> This method uses optional numeric methods to exit and continue keywords:
Bad because of code maintenance/updating.
> The final method is labeled loops, in which I will make a slightly more
> advanced
> example.
If loops are going to be exited from, labels should do the trick.
From what I've seen, it's likely that inner loops won't be labeled. People
always seem to want to exit out of loops that are further away.
5. Re: Exiting multiple loop constructs
I reject the 'numbered' loop approach due to the added work it requires during
maintenance.
> The final method is labeled loops, in which I will make a slightly more
> advanced
> example.
>
> }}}
<eucode>
> while 1 label top do
> for i = 1 to 10 label mid do
> for j = 1 to 10 label bottom do
> -- exit current loop "to" the top loop
> if j = 2 then exit top end if
>
> -- exit all loops (in this function)
> if j = 5 then exit all end if
> end for
> end for
> end while
> </eucode>
{{{
You seem to be saying that 'exit' means 'exit TO' rather than the existing
meaning of 'exit FROM'.
To me, the label identifies a loop and the 'exit <name>' construct means 'stop
executing code in the loop called <name> and commence at the next statement after
the loop's "end" statement' and it should not mean 'proceed immediately to the
start of the loop called <name> and increment the counter'. That is the meaning
of the 'next' keyword.
In short ...
... 'exit' should mean EXIT FROM the (named) loop.
... 'next' should mean begin the NEXT iteration of the (named) loop.
... 'retry' should mean RETRY the same iteration of the (named) loop.
So I would rewrite your eaxmple as ...
while 1 label top do
for i = 1 to 10 label mid do
for j = 1 to 10 label bottom do
-- stop processing current loop and go to the top loop
if j = 2 then next top end if
-- exit current loop and go to end of mid loop
if j = 4 then exit mid end if
-- exit all loops (in this function)
if j = 5 then exit all end if
end for
end for
end while
> Should any syntax change to support exiting multiple loops?
Huh? Do you mean exiting from deeply nested loops or are you referring to
something else. In any case the 'exit all' phrase is a bit redundant because, as
per your example, one could code 'exit top' and the topmost loop is labelled.
I'm thinking that the 'label' syntax is just too easy to overlook as it makes
the code seem cluttered. Maybe using some punctuation might help make it stand
out?
while 1 :top: do
for i = 1 to 10 :mid: do
for j = 1 to 10 :bottom: do
while 1 @top do
for i = 1 to 10 @mid do
for j = 1 to 10 @bottom do
I do think that the label needs to be to the left of the 'do' but maybe it can
actually be to the left of the loop statement.
@top while 1 do
@mid for i = 1 to 10 do
@bottom for j = 1 to 10 do
because then it could be made to standout even more by placing it on its own
line ...
@top
while 1 do
@mid
for i = 1 to 10 do
@bottom
for j = 1 to 10 do
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
6. Re: Exiting multiple loop constructs
> On 13 May 2008 at 18:58, Jeremy Cowgar wrote (maybe snipped):
> We've talked about labeled loops and a bit about existing loop
> constructs, exiting loops, etc... but I do not think we came to any
> conclusive decision. Here is a summary of different methods of exiting
> multiple loops:
>
> }}}
<eucode>
> integer in_top
> in_top = 1
>
> while in_top do
> for i = 1 to 10 do
> if i = 3 then
> in_top = 0
> exit
> end if
> end for
> end while
> </eucode>
{{{
>
> This will work fine unless you have processing *under* the nested
> loop, then you must provide an extra condition check (which is in a
> loop and is executed each iteration):
>
> }}}
<eucode>
> integer in_top
> in_top = 1
>
> while in_top do
> for i = 1 to 10 do
> if i = 3 then
> in_top = 0
> exit
> end if
> end for
> if in_top = 0 then
> exit
> end if
> -- do more processing here
> end while
> </eucode>
{{{
>
> NOTE: The above two methods compound in complexity with each nested
> loop you add. However, in real life, I'm not sure if I have ever
> programmed a loop that is 3 deep.
>
> This method uses optional numeric methods to exit and continue
> keywords:
>
> }}}
<eucode>
> while 1 do
> for i = 1 to 10 do
> if i = 3 then exit 2 -- end if
> end for
> end while
> </eucode>
{{{
>
> Notice "exit 2". That means exit 2 loops.
>
> The final method is labeled loops, in which I will make a slightly
> more advanced example.
>
> }}}
<eucode>
> while 1 label top do
> for i = 1 to 10 label mid do
> for j = 1 to 10 label bottom do
> -- exit current loop "to" the top loop
> if j = 2 then exit top end if
>
> -- exit all loops (in this function)
> if j = 5 then exit all end if
> end for
> end for
> end while
> </eucode>
{{{
>
>
> So. Is one clearer than another? I do not know. Should any syntax
> change to support exiting multiple loops? I am not sure, the benefit
> is you can remove multiple checks making code easier to write and
> better performing.
>
> So, what do you think? Are there other ways that I missed? What should
> be done?
>
Jeremy, the last method is obviously the best as it provides
additional flow control. Alas, I still in doubt about "exit" keyword
behavior. I'm sorry to insist, but maybe I should exemplify.
while 1 label top do
+-> ...
| for i = 1 to 10 label mid do
| for j = 1 to 10 label bottom do
| -- exit current loop "to" the top loop
| if j = 2 then
+------------<- exit top
elseif j = 7 then
+------------<- continue top
| end if
|
| -- exit all loops (in this function)
| if j = 5 then exit all end if ->+
| end for |
| end for |
+-> ... |
end while |
... <---------------------------------------+
Did I get it right or should I go after an ice-cream cone to stick it
in the head? :P
Best,
Euler
--
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com
7. Re: Exiting multiple loop constructs
Euler German wrote:
> Alas, I still in doubt about "exit" keyword
> behavior. I'm sorry to insist, but maybe I should exemplify.
I see how it should behave as very different from the diagram the Euler drew. I
see it as ...
while 1 label top do
+-> ...
| for i = 1 to 10 label mid do
| for j = 1 to 10 label bottom do
| if j = 2 then
| exit top -----------------------+
| elseif j = 7 then |
+------------<- continue top |
end if |
|
if j = 5 then exit all end if ->+ |
end for | |
end for | |
end while | |
... <---------------------------------------+ |
... <-----------------------------------------+
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
8. Re: Exiting multiple loop constructs
Gah, I missed that. I agree, Derek, that it should be exit from, not exit to.
Derek Parnell wrote:
> I'm thinking that the 'label' syntax is just too easy to overlook as it makes
> the code seem cluttered. Maybe using some punctuation might help make it stand
> out?
>
> }}}
<eucode>
> while 1 :top: do
> for i = 1 to 10 :mid: do
> for j = 1 to 10 :bottom: do
> </eucode>
{{{
>
> }}}
<eucode>
> while 1 @top do
> for i = 1 to 10 @mid do
> for j = 1 to 10 @bottom do
> </eucode>
{{{
>
> I do think that the label needs to be to the left of the 'do' but maybe it can
> actually be to the left of the loop statement.
> }}}
<eucode>
> @top while 1 do
> @mid for i = 1 to 10 do
> @bottom for j = 1 to 10 do
> </eucode>
{{{
>
> because then it could be made to standout even more by placing it on its own
> line ...
>
> }}}
<eucode>
> @top
> while 1 do
> @mid
> for i = 1 to 10 do
> @bottom
> for j = 1 to 10 do
> </eucode>
{{{
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
I agree that maybe the label should be before the loop, but I really don't like
the punctuation in place of a keyword. I find the word label far easier to read
than a decorating symbol, too many of which end up looking like line noise.
Maybe crib from other languages again?
label outer: while count < last_item do
label inner: -- can also appear on its own line
for i = 1 to length(stuff) do
if stuff[i] = BADVALUE then exit outer -- leaves both loops
elsif stuff[i] > LIMIT then continue inner -- goes to next iteration
else mung(stuff[i])
end if
end for
end while
Nah, that might not work because it might not be linked to the end <loop>
statement.
What about "dolabel"?
while count < last_item dolabel outer
for i = 1 to length(stuff) dolabel inner
if stuff[i] = BADVALUE then exit outer -- leaves both loops
elsif stuff[i] > LIMIT then continue inner -- goes to next iteration
else mung(stuff[i])
end if
end for
end while
Just brainstorming.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
9. Re: Exiting multiple loop constructs
Derek Parnell wrote:
>
> I reject the 'numbered' loop approach due to the added work it requires during
> maintenance.
I agree. Just including them all 
> In short ...
> ... 'exit' should mean EXIT FROM the (named) loop.
>
> ... 'next' should mean begin the NEXT iteration of the (named) loop.
>
> ... 'retry' should mean RETRY the same iteration of the (named) loop.
>
Yes, that makes better sense (although I am still in favor of continue instead
of next, but that's another discussion that has not yet finished ).
>
> > Should any syntax change to support exiting multiple loops?
>
> Huh? Do you mean ... <snip>
I mean, do we need to make this change or is the current multiple
check/condition that exists in Euphoria right now OK for loops.
>
> I'm thinking that the 'label' syntax is just too easy to overlook as it makes
> the code seem cluttered. Maybe using some punctuation might help make it stand
> out?
The label keyword I think, unless Rob or Matt has a better idea, pretty
important because it fits the idea of how the parser works. For instance, I can
say in the parsing code:
tok = next_token()
if tok[T_ID] = LABEL then
loop_label = StringToken()
else
putback(tok)
end if
I am not sure how an unidentified label would fit into the parsing scheme. The
thing is for certain that we want *optional* labels. I could easily parse:
while 1 :top: do
--- or ---
while 1 @top do
--- or any other thing ---
if a label was required, but we absolutely do not want to require a label. Now
bear in mind, that when you load the source in your editor (if it does syntax
highlighting) that it the keyword label will highlight just as an optional "by"
keyword highlights in a for loop:
for i = 1 to 10 by 2 do
If your editor is nice enough, it may even be able to make the word after the
label bright flashing red, green and blue colors for you
> }}}
<eucode>
> @top while 1 do
> @mid for i = 1 to 10 do
> @bottom for j = 1 to 10 do
> </eucode>
{{{
Syntax parsing would have to change to make this work, I do not think that's
somewhere I want to venture due to understanding of the parser still. If
something like that is the final decision, then Matt or Rob will have to step in.
However, I must say, that I personally think it's very distracting. The key to
those lines is not what the label is, it is the fact they are a while, for and
for loop. But with the @top, @mid, @bottom, the "while", "for" and "for" are then
lost. I think the labels are secondary to the function that's being performed.
--
Jeremy Cowgar
http://jeremy.cowgar.com
10. Re: Exiting multiple loop constructs
Derek Parnell wrote:
>
> I see how it should behave as very different from the diagram the Euler drew.
> I see it as ...
>
> }}}
<eucode>
> while 1 label top do
> +-> ...
> | for i = 1 to 10 label mid do
> | for j = 1 to 10 label bottom do
> | if j = 2 then
> | exit top -----------------------+
> | elseif j = 7 then |
> +------------<- continue top |
> end if |
> |
> if j = 5 then exit all end if ->+ |
> end for | |
> end for | |
> end while | |
> ... <---------------------------------------+ |
> ... <-----------------------------------------+
> </eucode>
{{{
>
I like this. And also, to this effect, there would not need to be a predefined
label "all" as previously stated in one of the messages.
--
Jeremy Cowgar
http://jeremy.cowgar.com
11. Re: Exiting multiple loop constructs
Jason Gade wrote:
>
> I agree that maybe the label should be before the loop, but I really don't
> like
> the punctuation in place of a keyword. I find the word label far easier to
> read
> than a decorating symbol, too many of which end up looking like line noise.
>
> Maybe crib from other languages again?
>
> }}}
<eucode>
> label outer: while count < last_item do
> label inner: -- can also appear on its own line
> for i = 1 to length(stuff) do
> if stuff[i] = BADVALUE then exit outer -- leaves both loops
> elsif stuff[i] > LIMIT then continue inner -- goes to next
> iteration
> else mung(stuff[i])
> end if
> end for
> end while
> </eucode>
{{{
>
Here again, I think this takes away from the purpose and makes code *very* hard
to read and understand. label is an optional parameter for a while/for keyword.
The while and for keywords are the important part of the line. The label is 100%
secondary. Also, the above syntax and one proposed by Derek would make you think
you could:
@again if 1 = 20 then
Which you cannot.
for a = 1 to length(lines) by 2 label top do
end for
is clear, understandable, readable and not confusing the matter that the for
loop is labeled TOP.
Now, if you want to make it stand out, use syntax highlighting or make it all
caps?
for a = 1 to length(lines) by 2 label TOP do
end for
--
Jeremy Cowgar
http://jeremy.cowgar.com
12. Re: Exiting multiple loop constructs
Well, I said "maybe" and came up with a different solution later on in the same
post.
I had rejected this solution because it doesn't link the label as tightly to the
loop as does having the label after the loop statement.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
13. Re: Exiting multiple loop constructs
Jason Gade wrote:
>
> Well, I said "maybe" and came up with a different solution later on in the
> same
> post.
>
> I had rejected this solution because it doesn't link the label as tightly to
> the loop as does having the label after the loop statement.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
Er, I meant my own example that you quoted. Not your example.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
14. Re: Exiting multiple loop constructs
Jason Gade wrote:
>
> Well, I said "maybe" and came up with a different solution later on in the
> same
> post.
>
> I had rejected this solution because it doesn't link the label as tightly to
> the loop as does having the label after the loop statement.
>
Opps. I misunderstood. I understand what you meant now. Sorry.
--
Jeremy Cowgar
http://jeremy.cowgar.com
15. Re: Exiting multiple loop constructs
Jeremy Cowgar wrote:
> The label keyword I think, unless Rob or Matt has a better idea,
> pretty important because it fits the idea of how the parser works.
Ok, I see what you mean, namely that the concept of a 'label' is that it is an
optional component of the 'loop' statement, and not a statement in its own right.
Fair enough, I'll stay within that boundary (for now).
Do the parsing rules mean that this below would be valid ...
while 1 label :top: do
In other words, the symbol used to name a label can contain any character except
whitespace and cannot start with either a digit or '#' or '--'. So it would be
okay (if not a bit over-the-top) to have ...
while true
label &&MAIN-PROCESSING-BLOCK:
do
. . .
end while
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
16. Re: Exiting multiple loop constructs
Derek Parnell wrote:
>
>
> Ok, I see what you mean, namely that the concept of a 'label' is that it is
> an optional component of the 'loop' statement, and not a statement in its own
> right. Fair enough, I'll stay within that boundary (for now).
>
>
> Do the parsing rules mean that this below would be valid ...
> }}}
<eucode>
> while 1 label :top: do
> </eucode>
{{{
I tried, that works fine.
> In other words, the symbol used to name a label can contain any character
> except
> whitespace and cannot start with either a digit or '#' or '--'. So it would
> be okay (if not a bit over-the-top) to have ...
>
> }}}
<eucode>
> while true
> label &&MAIN-PROCESSING-BLOCK:
> do
> . . .
> end while
> </eucode>
{{{
I tried that too. It works also.
Also:
while 1
label 25
do
. . .
end while
Works too, although, please do not use it 
... The key is it must not contain
a space.
--
Jeremy Cowgar
http://jeremy.cowgar.com
17. Re: Exiting multiple loop constructs
Jeremy Cowgar wrote:
>
> Derek Parnell wrote:
> >
> >
> > Ok, I see what you mean, namely that the concept of a 'label' is that it is
> > an optional component of the 'loop' statement, and not a statement in its
> > own
> > right. Fair enough, I'll stay within that boundary (for now).
> >
> >
> > Do the parsing rules mean that this below would be valid ...
> > }}}
<eucode>
> > while 1 label :top: do
> > </eucode>
{{{
>
> I tried, that works fine.
>
> > In other words, the symbol used to name a label can contain any character
> > except
> > whitespace and cannot start with either a digit or '#' or '--'. So it would
> > be okay (if not a bit over-the-top) to have ...
> >
> > }}}
<eucode>
> > while true
> > label &&MAIN-PROCESSING-BLOCK:
> > do
> > . . .
> > end while
> > </eucode>
{{{
>
> I tried that too. It works also.
>
> Also:
>
> }}}
<eucode>
> while 1
> label 25
> do
> . . .
> end while
> </eucode>
{{{
>
> Works too, although, please do not use it ... The key is it must not
> contain
> a space.
Kool, we have targets of various forms! Now, onto the keyword for a target:
goto!
Kat
18. Re: Exiting multiple loop constructs
Kat wrote:
>
> Kool, we have targets of various forms! Now, onto the keyword for a target:
> goto!
>
> Kat
A rose, by any other name...
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
19. Re: Exiting multiple loop constructs
Jeremy Cowgar wrote:
>
> We've talked about labeled loops and a bit about existing loop constructs,
> exiting
> loops, etc... but I do not think we came to any conclusive decision. Here is
> a summary of different methods of exiting multiple loops:
>
> }}}
<eucode>
> integer in_top
> in_top = 1
>
> while in_top do
> for i = 1 to 10 do
> if i = 3 then
> in_top = 0
> exit
> end if
> end for
> end while
> </eucode>
{{{
>
> This will work fine unless you have processing *under* the nested loop, then
> you must provide an extra condition check (which is in a loop and is executed
> each iteration):
>
> }}}
<eucode>
> integer in_top
> in_top = 1
>
> while in_top do
> for i = 1 to 10 do
> if i = 3 then
> in_top = 0
> exit
> end if
> end for
> if in_top = 0 then
> exit
> end if
> -- do more processing here
> end while
> </eucode>
{{{
>
> NOTE: The above two methods compound in complexity with each nested loop you
> add. However, in real life, I'm not sure if I have ever programmed a loop that
> is 3 deep.
>
> This method uses optional numeric methods to exit and continue keywords:
>
> }}}
<eucode>
> while 1 do
> for i = 1 to 10 do
> if i = 3 then exit 2 -- end if
> end for
> end while
> </eucode>
{{{
>
> Notice "exit 2". That means exit 2 loops.
>
> The final method is labeled loops, in which I will make a slightly more
> advanced
> example.
>
> }}}
<eucode>
> while 1 label top do
> for i = 1 to 10 label mid do
> for j = 1 to 10 label bottom do
> -- exit current loop "to" the top loop
> if j = 2 then exit top end if
>
> -- exit all loops (in this function)
> if j = 5 then exit all end if
> end for
> end for
> end while
> </eucode>
{{{
>
>
> So. Is one clearer than another? I do not know. Should any syntax change to
> support exiting multiple loops? I am not sure, the benefit is you can remove
> multiple checks making code easier to write and better performing.
>
> So, what do you think? Are there other ways that I missed? What should be
> done?
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
There is another way:
procedure nested_loops(sequence args)
for i=1 to 27 do
while f(x)=3 do
....
if exit_em_all() then
return
end if
end end.... end
end procedure
-- ... some code
nested_loops(args)
and after all, nesd_loops() may be a function as well.
While this works well at top leel, it is less obvious in a routine, beause
nested_loops() may access the privates of the calling routines.
If, like Æ or Pascal, Euphoria had nested routines, it would work fine. And the
chagnges are not that difficult really.
The method you quote first is what e are doing now. Error prone, invites a goto
statement to make the code more maintainable.
Method #2 is good in small programs, the code is the cleaest, but maintaining is
tricky because ading/removing a loop level will cause to examine all
exit/continue statements.
Method #3 is more heavyhanded, but after all, not all loops are affected, and
maintaining is the easiest.
Methood #4 has been available, but does not always work, or becomes as error
prone as #1 when privates have to be passed and updated.
My suggestion would be to add method #3, possibly adding #2. For #2, things can
be made less fragile by being able to use non positive optional arguments - exit
0 would exit all loops, exit -1 all but the topmost, etc. Like when using $ for
sequences.
Alternatively, if we had nested routines, we'd solve a few more problems and
could always use method #4. Perhaps the best.
CChris
20. Re: Exiting multiple loop constructs
Jason Gade wrote:
>
> My only real concern is the placement of the "label" statement. Not sure where
> it should go to be most clear.
>
> I don't like the "all" option, you should know the label of the highest level
> you are exiting. No need for a predefined label, IMO.
>
> I'm not sure what kinds of stack cleanup/unwinding would need to be done in
> order to prevent memory/resource leaks and/or fill up the interpreter's stack
> with data from exited loops.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
None.
The parser doesn't exit your loops, ig plows sequentially through them. There is
a stack of requested exits, and, at each end for/end while, they are examined,
and thoe who are ripe get backpatched appropriately. The stack grows when an exit
statement is met, and shrinks when all end exit requests are marked as processed.
At least that's how I implemented it.
So, there is a stack,, but it dosn't grow larger than the deepest loop nesting
level in program. Stack overflow is very unlikely.
CChris
