1. Exit(n) vs. goto
-------Phoenix-Boundary-07081998-
A personal opinion on the inadvisability of 'exit(n)'.
The problem of breaking out of nested loops is real
but exit(n) is a bit of a write-only way of
handling it.
Ask yourself- Is the purpose of exit(N)
to break out of N loops, or is it to get to
a specific location in the code (which happens
to be at the end of a specific loop).
A loop that includes an exit(n) statement is making
assumptions about the structure of its environment.
Finding the target of exit(3) can be difficult,
involving the counting, both up and down, of 2
kinds of loops, possibly over several pages of
code. You can't even use your editor to do the
search!
Changing the nesting structure of the code
can require fixing exit() statements.
The typical use of exit(N) would be when some
significant milestone in the processing occured:
'error_found', or 'start_next_step'. 'exit(N)'
gives no clue.
Goto is more semanticly meaningful, more
versatile, runs faster and its target is more
easily found.
Karl Bochert
-------Phoenix-Boundary-07081998---
2. Re: Exit(n) vs. goto
>----- Original Message -----
>From: <kbochert at ix.netcom.com>
>To: "EUforum" <EUforum at topica.com>
>Sent: Monday, February 18, 2002 4:37 AM
>Subject: Exit(n) vs. goto
>
>
>A personal opinion on the inadvisability of 'exit(n)'.
>
>The problem of breaking out of nested loops is real
>but exit(n) is a bit of a write-only way of
>handling it.
>
>Ask yourself- Is the purpose of exit(N)
>to break out of N loops, or is it to get to
>a specific location in the code (which happens
>to be at the end of a specific loop).
>
>A loop that includes an exit(n) statement is making
>assumptions about the structure of its environment.
>
>Finding the target of exit(3) can be difficult,
>involving the counting, both up and down, of 2
>kinds of loops, possibly over several pages of
>code. You can't even use your editor to do the
>search!
>
>Changing the nesting structure of the code
>can require fixing exit() statements.
>
>The typical use of exit(N) would be when some
>significant milestone in the processing occured:
>'error_found', or 'start_next_step'. 'exit(N)'
>gives no clue.
>
Up to this point in your argument I agree.
>Goto is more semanticly meaningful, more
>versatile, runs faster and its target is more
>easily found.
This is where we part company. If we use "semanticly" to mean that it
conveys meaning, then GOTO is in fact less semantically meaningful than
EXIT. My reasoning is that GOTO means that the logic flow jumps somewhere
into the code. We don't know where (in a logical sense) until we read and
possible examine the program. Where as EXIT also means that the logic flow
jumps, but we know exactly where - the next statement after the looping
logic we are in. We don't have to examine the code. We already know which
lines it jumps over. Granted, in a physical sense, we still have to use our
eyes to find that 'next statement', but in a logic sense, it is total clear.
The problems with EXIT(N) are as you have said earlier. The issue is with
the (N) part. But if we go back to what EXIT means, 'leaves the loop', then
to extend this into a facility to leave a nested loop, it might be better to
identify which loop you are trying to leave. With the(N) method there are
problems, the chief being that when you (or others) modify the code, they
must always recheck that the (N) still refers to the correct nesting depth.
Another method of identify the loop is to give it a name, which of course
doesn't change as you modify the code in future. Then the EXIT statement
nominates the name of the loop it wants to exit. In this way we get the
semantic benefit (EXIT means leave a loop), and maintenance benefit (the
loop's name doesn't change unless we specifically change it).
As for execution speed, it should be identical to GOTO as it does the same
sort of processing. And it avoids the potential problem of jumping to
arbitrary code location that is NOT the end of a loop. Also with GOTO one
must seek its target when looking through the code. It could be earlier or
later than the loop we are in.
I wouldn't want to introduce a syntax for this concept yet but I'm sure the
example below is self-explanitory...
Scans:for i = 1 to length(s) do
c = getc(h)
while find(c, charlist) do
if c = AbortCode then
exit (ScanS)
end if
RoutineA(c)
end while
RoutineB()
end Scans
(I'd also like to get rid of this silly 'end for', 'end while', 'end
procedure', 'end function' stuff. Just a maintenance headache and serves no
useful purpose, but that's another issue 
)
-----
cheers,
Derek.
3. Re: Exit(n) vs. goto
Hello Derek:
On 18 Feb 2002, at 7:30, Derek Parnell wrote:
>
> >----- Original Message -----
> >From: <kbochert at ix.netcom.com>
> >To: "EUforum" <EUforum at topica.com>
> >Sent: Monday, February 18, 2002 4:37 AM
> >Subject: Exit(n) vs. goto
> >
>
> >A personal opinion on the inadvisability of 'exit(n)'.
> >
> >The problem of breaking out of nested loops is real
> >but exit(n) is a bit of a write-only way of
> >handling it.
> >
> >Ask yourself- Is the purpose of exit(N)
> >to break out of N loops, or is it to get to
> >a specific location in the code (which happens
> >to be at the end of a specific loop).
> >
> >A loop that includes an exit(n) statement is making
> >assumptions about the structure of its environment.
> >
> >Finding the target of exit(3) can be difficult,
> >involving the counting, both up and down, of 2
> >kinds of loops, possibly over several pages of
> >code. You can't even use your editor to do the
> >search!
> >
> >Changing the nesting structure of the code
> >can require fixing exit() statements.
> >
> >The typical use of exit(N) would be when some
> >significant milestone in the processing occured:
> >'error_found', or 'start_next_step'. 'exit(N)'
> >gives no clue.
> >
>
> Up to this point in your argument I agree.
>
> >Goto is more semanticly meaningful, more
> >versatile, runs faster and its target is more
> >easily found.
>
> This is where we part company. If we use "semanticly" to mean that it
> conveys meaning, then GOTO is in fact less semantically meaningful than
> EXIT. My reasoning is that GOTO means that the logic flow jumps
> somewhere into the code. We don't know where (in a logical sense) until
> we read and possible examine the program. Where as EXIT also means that
> the logic flow jumps, but we know exactly where - the next statement
> after the looping logic we are in. We don't have to examine the code. We
> already know which lines it jumps over. Granted, in a physical sense, we
> still have to use our eyes to find that 'next statement', but in a logic
> sense, it is total clear.
>
> The problems with EXIT(N) are as you have said earlier. The issue is
> with the (N) part. But if we go back to what EXIT means, 'leaves the
> loop', then to extend this into a facility to leave a nested loop, it
> might be better to identify which loop you are trying to leave. With
> the(N) method there are problems, the chief being that when you (or
> others) modify the code, they must always recheck that the (N) still
> refers to the correct nesting depth.
>
> Another method of identify the loop is to give it a name, which of
> course doesn't change as you modify the code in future. Then the EXIT
> statement nominates the name of the loop it wants to exit. In this way
> we get the semantic benefit (EXIT means leave a loop), and maintenance
> benefit (the loop's name doesn't change unless we specifically change
> it).
>
> As for execution speed, it should be identical to GOTO as it does the
> same sort of processing. And it avoids the potential problem of jumping
> to arbitrary code location that is NOT the end of a loop. Also with GOTO
> one must seek its target when looking through the code. It could be
> earlier or later than the loop we are in.
>
> I wouldn't want to introduce a syntax for this concept yet but I'm sure
> the example below is self-explanitory...
>
> Scans:for i = 1 to length(s) do
> c = getc(h)
> while find(c, charlist) do
> if c = AbortCode then
> exit (ScanS)
> end if
> RoutineA(c)
> end while
> RoutineB()
> end Scans
>
I liked your suggestion but this way we'll create a label (or some kind
of). Don't you agree that *interpreter* knows loop's boundaries? What I
mean by exit(N) is *execute next line after the Nth. loop. Today we use
flags to control deep nested loops exiting. Don't you think we could
have *automatic inner flags* to do the same. Ok, I'm lazy, but I
wouldn't have to set a flag and test it at each loop end just to see if
is farewell time. 
> (I'd also like to get rid of this silly 'end for', 'end while', 'end
> procedure', 'end function' stuff. Just a maintenance headache and serves
> no useful purpose, but that's another issue )
>
Agreed, let's talk about later though I think it makes sense.
> -----
> cheers,
> Derek.
>
Cheers,
-- Euler
4. Re: Exit(n) vs. goto
-------Phoenix-Boundary-07081998-
Hi Derek Parnell, you wrote on 2/17/02 12:30:56 PM:
>Goto is more semanticly meaningful, more
>versatile, runs faster and its target is more
>easily found.
>
>This is where we part company. If we use "semanticly" to mean that it
>conveys meaning, then GOTO is in fact less semantically meaningful than
>EXIT. My reasoning is that GOTO means that the logic flow jumps somewhere
>into the code.
'goto error' seems fairly meaningful, especially as compared
to 'exit(3)'.
> We don't know where (in a logical sense) until we read and
>possible examine the program. Where as EXIT also means that the logic flow
>jumps, but we know exactly where - the next statement after the looping
>logic we are in. We don't have to examine the code. We already know which
>lines it jumps over. Granted, in a physical sense, we still have to use our
>eyes to find that 'next statement', but in a logic sense, it is total
>clear.
>
>The problems with EXIT(N) are as you have said earlier. The issue is with
>the (N) part. But if we go back to what EXIT means, 'leaves the loop', then
>to extend this into a facility to leave a nested loop, it might be better
>to
>identify which loop you are trying to leave. With the(N) method there are
>problems, the chief being that when you (or others) modify the code, they
>must always recheck that the (N) still refers to the correct nesting depth.
>
>Another method of identify the loop is to give it a name, which of course
>doesn't change as you modify the code in future. Then the EXIT statement
>nominates the name of the loop it wants to exit. In this way we get the
>semantic benefit (EXIT means leave a loop), and maintenance benefit (the
>loop's name doesn't change unless we specifically change it).
>
Much better. I am not opposed to 'exit' or 'exit (srch_loop)'. (But
'exit (srch_loop)' seems pretty equivalent to 'goto end_srch_loop').
>As for execution speed, it should be identical to GOTO as it does the same
>sort of processing.
I think you're right.
> And it avoids the potential problem of jumping to
>arbitrary code location that is NOT the end of a loop.
One programmer's potential problem is another's tool.
> Also with GOTO one
>must seek its target when looking through the code. It could be earlier or
>later than the loop we are in.
>
I would rather search for the label than take the risk of miscounting
'end while/for' as I scan through multiple pages. In practice,
the name of the lable usually indicates its direction, and an editor's
search capability make this easy.
>I wouldn't want to introduce a syntax for this concept yet but I'm sure the
>example below is self-explanitory...
>
> Scans:for i = 1 to length(s) do
> c = getc(h)
> while find(c, charlist) do
> if c = AbortCode then
> exit (ScanS)
> end if
> RoutineA(c)
> end while
> RoutineB()
> end Scans
>
Not bad. Use of 'end Scans' instead of 'end for' greatly
simplifies finding the target of exit, and should also
improve the readability.
Shouldn't you also have a 'continue (Scans)' statement?
Given that this exercise is to simplify nested loops, it would
be a shame to add an enclosing while loop just to be able to
restart a loop.
I prefer the goto -- a little more versatile, a little more
subject to abuse -- because it calls attention to itself a little
more, but this scheme is a very close second.
(perhaps the biggest thing that goto has going for it is that
I've already implemented it!)
Karl
-------Phoenix-Boundary-07081998---
5. Re: Exit(n) vs. goto
>(I'd also like to get rid of this silly 'end for', 'end >while', 'end
>procedure', 'end function' stuff. Just a maintenance >headache and serves
>no
>useful purpose, but that's another issue )
Have you done C programming? Do you know how ANNOYING trying to chase down {
and } characters are in a deeply nested for & if loop?
Just for the record, I have no problems with constructing for and if loops
3-4 levels deep, because as long as it is indented properly, it is very easy
to understand.
=====================================================
.______<-------------------\__
/ _____<--------------------__|===
||_ <-------------------/
\__| Mr Trick
6. Re: Exit(n) vs. goto
18/02/2002 9:17:52 AM, kbochert at ix.netcom.com wrote:
>
>Hi Derek Parnell, you wrote on 2/17/02 12:30:56 PM:
>
Firstly, I'm not arguing for or against the GOTO per se in this particular
discussion. I could! But
I'm not. I'm specifically examining the use of GOTO as a method of exiting
loops.
>>Goto is more semanticly meaningful, more
>>versatile, runs faster and its target is more
>>easily found.
>
>
>>This is where we part company. If we use "semanticly" to mean that it
>>conveys meaning, then GOTO is in fact less semantically meaningful than
>>EXIT. My reasoning is that GOTO means that the logic flow jumps somewhere
>>into the code.
>
>'goto error' seems fairly meaningful, especially as compared
>to 'exit(3)'.
>
Maybe? I'm not sure. To me, GOTO means "jump somewhere", and EXIT means "I want
to leave a loop".
The difference is that a GOTO does not convey the coder's intention where as
EXIT has a better
chance of doing that. Even with disciplined naming conventions, a GOTO can still
mislead a person
reading the code.
With a GOTO, it is never clear from the statement itself, if the coder is trying
to leave a loop or
not. One can only know if you find the target of the GOTO and see if it is
outside the loop or not.
Even if the coder writes "GOTO exit_srchloop" we cannot be sure if the label
exit_srchloop is
actually outside the loop or not until we locate it when reading the code.
There is always a danger in trying to convey meaning in an identifier's name. Of
course we all try
do that, but often it is hard. I'm reminded of a (stupid?) junior programmer
that thought he has
having a joke and coded something like this...
constant HUNDRED = 100,
THOUSAND = 10 * HUNDRED - 1,
MILLION = 10 * THOUSAND
and thus when the constants were used in code, other people would have a
terrible time trying to
debug the code when reading it. Or a Forth programmer doing this : + - ;
(redefining the plus sign
to mean minus!).
>>Another method of identify the loop is to give it a name, which of course
>>doesn't change as you modify the code in future. Then the EXIT statement
>>nominates the name of the loop it wants to exit. In this way we get the
>>semantic benefit (EXIT means leave a loop), and maintenance benefit (the
>>loop's name doesn't change unless we specifically change it).
>>
>
>Much better. I am not opposed to 'exit' or 'exit (srch_loop)'. (But
>'exit (srch_loop)' seems pretty equivalent to 'goto end_srch_loop').
>
It is except that EXIT tells you that the coder wants to leave a loop, but GOTO
only tells you that
the coder wants to go somewhere else.
>> And it avoids the potential problem of jumping to
>>arbitrary code location that is NOT the end of a loop.
>
>One programmer's potential problem is another's tool.
>
Again, I'm not talking about GOTO per se, just leaving a loop. Consider...
for i = 1 to 100 do
. . .
if x then goto exit_scan end if
. . .
end for
cnt += 1
:exit_scan:
In this case, not only does the code leave the loop, it also ignores the code
immediately following
the loop, thus possibly introducing a bug and misleading a person reading the
loop code. It is made
even more misleading because it allows for this too:
if y then goto exit_scan end if
for i = 1 to 100 do
. . .
if x then goto exit_scan end if
. . .
end for
cnt += 1
:exit_scan:
Now, the label 'exit_scan' has really lost its meaning. This does not help
people reading your code.
>> Also with GOTO one
>>must seek its target when looking through the code. It could be earlier or
>>later than the loop we are in.
>>
>
>I would rather search for the label than take the risk of miscounting
>'end while/for' as I scan through multiple pages. In practice,
>the name of the lable usually indicates its direction, and an editor's
>search capability make this easy.
>
Me too. That's one of the reasons I don't like exit(n) syntax.
>>I wouldn't want to introduce a syntax for this concept yet but I'm sure the
>>example below is self-explanitory...
>>
>> Scans:for i = 1 to length(s) do
>> c = getc(h)
>> while find(c, charlist) do
>> if c = AbortCode then
>> exit (ScanS)
>> end if
>> RoutineA(c)
>> end while
>> RoutineB()
>> end Scans
>>
>Not bad. Use of 'end Scans' instead of 'end for' greatly
>simplifies finding the target of exit, and should also
>improve the readability.
Thank you.
>Shouldn't you also have a 'continue (Scans)' statement?
>Given that this exercise is to simplify nested loops, it would
>be a shame to add an enclosing while loop just to be able to
>restart a loop.
Yes, I think this idea is also a good one, and I've discussed this with RDS
before. Using named
loops make the ideas of moving on to the next iteration and repeating the same
iteration much easier
on the eyes.
for i = 1 to 100 do:ScanLoop
. . .
-- Do the next iteration
if c then next Scanloop end if
. . .
-- Repeat the same iteration
if d then repeat Scanloop end if
. . .
-- Leave the loop
if e then exit ScanLoop end if
. . .
end ScanLoop
---------
Cheers,
Derek Parnell
7. Re: Exit(n) vs. goto
18/02/2002 11:23:30 AM, mistertrik at hotmail.com wrote:
>
>>(I'd also like to get rid of this silly 'end for', 'end >while', 'end
>>procedure', 'end function' stuff. Just a maintenance >headache and serves
>>no
>>useful purpose, but that's another issue )
>
>Have you done C programming?
I've been programming in C since 1979.
>Do you know how ANNOYING trying to chase down {
>and } characters are in a deeply nested for & if loop?
Too bloody right I do. Especially when they are optional!
if (cond1)
if (cond2)
RtnA;
else
RtnB;
RtnB gets executed when NOT cond1, and cond2 has nothing to do with it! Which is
most confusing.
>Just for the record, I have no problems with constructing for and if loops
>3-4 levels deep, because as long as it is indented properly, it is very easy
>to understand.
I too learned the value of consistant indentation sytle with C. I also now
always use braces with
if/for/while statements.
if (cond1)
{
if (cond2)
{
RtnA;
};
}
else
{
RtnB;
}
---------
Cheers,
Derek Parnell
8. Re: Exit(n) vs. goto
Euler,
I hope you don't mind me publishing your question in the Eu forum.
18/02/2002 2:15:28 PM, "Euler German" wrote:
>would be possible to have as much identified loops as
>we need? I mean, to handle situations when we could use a total, a mid
>term and a simple (not identified) exit.
Why not? I would not like to break any existing code so loop labels would have
to be optional. Also,
any loop could have a label. I suspect that the loop identifier should only be
scoped to the
containing routine (or file if its not in a routine). Though it might be argued
that the scope
should only be to the identifier loop and nested loops, similar to the automatic
index variable in
FOR loops.
for i = 1 to width do:bAcross
. . .
for j = 1 to Height do:bDown
. . .
if a then exit bAcross end if
. . .
while c do:bAnalysis
. . .
if b then exit bDown end if
if d then exit bAcross end if
. . .
end bAnalysis
. . .
end bDown
. . .
end bAcross
--------
Derek
9. Re: Exit(n) vs. goto
>18/02/2002 11:23:30 AM, mistertrik at hotmail.com wrote:
>
>>
>>>(I'd also like to get rid of this silly 'end for', 'end >while', 'end
>>>procedure', 'end function' stuff. Just a maintenance >headache and serves
>>>no
>>>useful purpose, but that's another issue )
>>
>>Have you done C programming?
>
>I've been programming in C since 1979.
>
>>Do you know how ANNOYING trying to chase down {
>>and } characters are in a deeply nested for & if loop?
>
I agree. I value READABLE CODE much more highly than conveniant
code editing shortcuts. The syntax was designed that way to make
readable, easy to de-bug code, and IMHO is entirely consistant with
the style of launguage that rds created, as described in refman.doc
im sure with your 20+ years looking at c code that these things
seem redundant, but I think the one big lesson that can be learnt
from the C-monster is the real world value of readable code.
Graeme.
10. Re: Exit(n) vs. goto
----- Original Message -----
From: "Graeme" <graemeburke at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Exit(n) vs. goto
> but I think the one big lesson that can be learnt
> from the C-monster is the real world value of readable code.
Reminds me of the saying "No one is completely useless, at the very least
you can stand as a good example of what not to be."
11. Re: Exit(n) vs. goto
>Reminds me of the saying "No one is completely useless, at the very least
>you can stand as a good example of what not to be."
>
Waxing philosophical derek? perhaps you would be so kind as to
provide us with the origon of the quote...
Graeme,
12. Re: Exit(n) vs. goto
----- Original Message -----
From: "Graeme" <graemeburke at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Exit(n) vs. goto
>
>
> >Reminds me of the saying "No one is completely useless, at the very least
> >you can stand as a good example of what not to be."
> >
>
> Waxing philosophical derek? perhaps you would be so kind as to
> provide us with the origon of the quote...
>
That was from memory, so I looked it up. So to quote Dr. Simon
Lipscomb-Allhouse, (Univ. Labs of Physiology, Oxford) who may in fact be
quoting somebody else...
"No-one is completely useless-They can always serve as a bad example."
13. Re: Exit(n) vs. goto
-------Phoenix-Boundary-07081998-
Hi Derek Parnell, you wrote on 2/17/02 4:39:07 PM:
>I too learned the value of consistant indentation sytle with C. I also now
>always use braces
>with
>if/for/while statements.
>
> if (cond1)
> {
> if (cond2)
> {
> RtnA;
> };
> }
> else
> {
> RtnB;
> }
Just to be opinionated
if (cond1) {
if (cond2) {
RtnA;
}
}
else {
RtnB;
}
Reasons:
1) Blank (or nearly blank) lines should be used as
'visual separators' to group related chunks of
code. (Unless you are getting paid by the line,
of course). One rarely wants to interrupt the
reader just after an if clause starts.
2) To my view, the '{}' after if are part of the
contents of the if clause, and deserve to be
indented just like the other contents.
3) Nobody else does it this way (It must be better).
Karl
-------Phoenix-Boundary-07081998---
14. Re: Exit(n) vs. goto
Of course not! As a matter of fact, only now I realize that you
answered me personally. Be my guest, Derek.
Cheers,
-- Euler
On 18 Feb 2002, at 15:21, Derek Parnell wrote:
> Euler,
> I hope you don't mind me publishing your question in the Eu forum.
>
> 18/02/2002 2:15:28 PM, "Euler German" wrote:
>
> >would be possible to have as much identified loops as
> >we need? I mean, to handle situations when we could use a total, a mid
> >term and a simple (not identified) exit.
>
> Why not? I would not like to break any existing code so loop labels
> would have to be optional. Also, any loop could have a label. I suspect
> that the loop identifier should only be scoped to the containing routine
> (or file if its not in a routine). Though it might be argued that the
> scope should only be to the identifier loop and nested loops, similar to
> the automatic index variable in FOR loops.
>
> for i = 1 to width do:bAcross
> . . .
> for j = 1 to Height do:bDown
> . . .
> if a then exit bAcross end if
> . . .
> while c do:bAnalysis
> . . .
> if b then exit bDown end if
> if d then exit bAcross end if
> . . .
> end bAnalysis
> . . .
> end bDown
> . . .
> end bAcross
>
> --------
> Derek
>
>
