Re: Euphoria features
David.Cuny wrote:
>Everett Williams wrote:
>
>> Did I miss something...exit can accomplish this one.
>
>Yes, the example was trivial.
Sorry about that, but you ignored the "skip" routine which I thought made
the deeper point. The skip routine encapsulated the items that were to be
intentionally skipped, documenting the intent. Goto documents nothing.
It is a high-altitude bomber that leaves no marks except on the target
where it is headed. That may be great in bombing, but it sure leaves lots
of questions in a program.
>
>I'd like to make my position on GOTOs more clear: I'm not really interested
>in adding a GOTO to Euphoria. Rather, I'm more interested in a good way of
>getting out of deeply nested logic structures in an efficient manner.
>
>Using flags is the 'correct' way of doing it, but the resulting code often
>seems to obscure the intent, rather than clarify it. Moving the block into a
>routine is possible, but sharing variables can be problematic in Euphoria,
>especially since they are scoped as local.
Well chosen, documented, and named flag variables usually resolve this
objection.
>I seem to recall that even the K&R text acknowleged that the GOTO is the
>best method of expressing that intent.
>
>The 'problem' with block structures is that they are local; they neither
>know about the blocks outside of themselves, or inside of them. If we were
>only talking about 'for' loops, than something like:
>
> for i = 1 to 10 do
> for j = 1 to 10 do
> ...
> leave i loop
> ...
> end for
> end for
>
>Would work. But there are 'while' loops as well. I suppose you could add
>labels to the loops, as in:
>
> outerWhile: while true do
> for i = 1 to 10 do
> ...
> leave outerWhile:
> ...
> end for
> end while
>
>This strikes me as being less clear than the pure GOTO, and it disallows
>instance where you have a series of instructions, but want to stop if an
>error is encountered:
>
> if handle = -1 then
> goto fileError:
> end if
>
> ...
> if writeResult = -1 then
> goto fileError:
> end if
> ...
> if closeFileResult = -1 then
> goto fileError:
> ...
> return
>
> fileError:
> ...
> return
>
>Yes, I know that you could set a flag, etc. But it still seems to me that
>the GOTO best expresses the intent of the code: if an error is encountered,
>skip the rest of the code and run the error handler.
>
>-- David Cuny
Ignoring the obvious elseif structure, let us assume a situation where
later on I decide to add some logic between return and fileError: for
whatever reason. If the code is large, will I remember that the return
does not in all cases lead to the fileError:? Maybe the code to be added
only needs to be run in certain cases. Multiply that times about five or
ten special cases as is often the condition in highly complex decisional
code. Without flags, I don't have anything to test for the various
combinations of decisions that I have to make. Furthermore, now I
have to find everybody that goes to this label and fix them to handle the
needed flags. That is the bottom problem with goto. It carries no information
with it in the way that a procedure stack does just by it's nature and
sequence.
Goto is like the guy that sees a fire in the bathroom as he turns
away from the urinal. He goes running out of the bathroom yelling fire.
Nobody is likely to tell him that he left his fly open and his wallet on the
sink. In a few minutes, he is going to realize the importance of these two
things. Since the fly is still attached(the flag) he can do something about
it. The wallet, however, is quite another matter. By the time he hits the
street, he may not even remember which bathroom that he was in.
That is the reason for not using goto's. I agree that the "shorter range"
ones that you speak of sound attractive, and would certainly be less
damaging than the more general type. However, one man's procedure may
be larger than somebody else's whole program. A goto can go across
several pages of code, even in the restricted situation.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
