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