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
|
Not Categorized, Please Help
|
|
