Re: GOTO considered necessary (reworked)

["John G. Volan" <johnvolan@sprintmail.com>]

Robert A Duff wrote:
> 
> In article <33A0840B.1B41@sprintmail.com>,
> John G. Volan <johnvolan@sprintmail.com> wrote:
> >I agree with that philosophy, but I'd clarify it: Gotos may be used only
> >as a _last_ resort, after every other possible structure has been
> >exhaustively tried and still found to be less understandable, or
> >maintainable, or efficient, or whatever, than the proposed goto
> >solution. ...
> 
> This seems like a strange attitude to me.  I mean, why not say the same
> thing about any other language feature, like if statements?  You
> shouldn't use an if statement if there is another way of writing the
> code that's more understandable, maintainable, or whatever.  The same
> applies to goto.  Why does that make goto a "last resort"?
>
> I certainly agree that there are lots more cases where if statements are
> appropriate than cases where goto is appropriate.  But both can be
> judged according to the same criteria -- as you said, "understandable,
> or maintainable, or efficient, or whatever".
> 

I could certainly be persuaded that, e.g., there are even some
situations where if statements would be a poor choice or a "last
resort".  But I think it's a matter of degree:  On the structural
continuum, gotos are considerably farther down in the primitive
direction.

Looking at the cases Sam Mize enumerates, I think they can all
essentially be boiled down to this: A programmer has a well-defined
control structure in mind (e.g., FSA's, or loop continue), but the
language does not provide a syntax for it (although such a syntax could
easily be imagined).

If the structure were available in the language, of course there would
be no question of using gotos for the same purpose.  Barring that, gotos
can be used to _simulate_ this structure, but this will always be a
dangerous practice, because the gotos are only at best a simulation of
the actual construct the programmer has in mind.  Gotos lack
"robustness"; certain important properties of the hypothetical structure
(e.g., prevention of "fall-through" between states in an FSA) cannot be
guaranteed except by programmer vigilance.

Yes, a very capable programmer may be quite skilled at navigating this
mine-field, and may be quite dilligent about documenting exactly what
structure is being simulated.  And a very skilled maintenance programmer
may be able to take such goto-laden code (and its documentation) and,
with a great deal of dilligence, successfully modify it when necessary,
without introducing accidental bugs that violate the desired properties
of the structure.

But even very skilled programmers are human and capable of errors or
omissions. It would be very useful if some automated tool (e.g., the
compiler) could provide the programmer with an analysis of whether this
use of goto satisfied the desired properties -- but the whole point is
that the compiler is incapable of this, by definition, because the
language lacked the desired construct in the first place. Bottom line,
the appearance of gotos in a program obligates both the original
programmer and all future maintainers to exert a greater than usual
effort to make sure that they get them right.

Therefore, if the programmer can think of a way to apply a different
structure to the problem, one which the language does support, then this
structure should tend to be favored over simulating a hypothetical
structure with gotos.  Of course, if the alternative structure reduces
efficiency or adds complexity (e.g., spurious levels of nesting,
auxiliary Boolean variables, or e.g. in an FSA, encoding the states with
an enumerated type), then this is a point against that alternative, and
the engineer must weigh this very carefully.

On the other hand, just because _some_ workarounds for avoiding gotos
have these undesirable properties does not automatically mean _all_
workarounds in _all_ situations will suffer from these maladies
(notwithstanding Robert Dewar's attempt to brand any suggestion along
these lines as being tantamount to advocating Boolean junk variables).
For example, in the specific case of that Insert operation, my point
(and I believe Jeff Carter's, too) was that wrapping it up as a
subprogram with multiple returns, and then inlining the subprogram, can
be every bit as efficient, no more complex, and considerably safer from
a maintenance point of view, than inlining it by hand with gotos instead
of returns. (And neither Jeff Carter nor I made _any_ mention of Boolean
junk variables for this case.)

Add to that the fact that, in that _specific case_, the Insert
subprogram is a useful, cohesive abstraction for an important operation
in the given problem domain, one with well-defined preconditions and
post-conditions which can be unit-tested, and one that might be usefully
called from many other places within the same program; then under these
circumstances, the choice for me at least would be very clear, and I
would look very critically at any claim that a goto solution would be
better.

> I would also agree, if you said, "As a rule of thumb, if you think you
> want to use a goto, think twice."

Well, that's exactly what I was trying to get across, but that's a very
nice way of putting it.

> By the way, for most programs, it seems far more important to worry
> about how you structure the thing using packages, types, subprograms,
> tasks, etc, than to worry about the control structures.  

Agreed. In fact, sometimes the temptation to resort to gotos may be
tip-off that there is a more general, systemic problem in the way your
application design has been laid out (in terms of, as you say,
high-level abstractions like packages, types, subprograms, etc.). For
instance, if I saw a lot of snippets of insertion code scattered through
a program that were all hand-inlined with gotos, I'd see that as a
failure on the part of the designer(s) to abstract out the common Insert
subprogram -- unless they _prominently_ documented the fact that they
only did this because their compiler's implementation of pragma Inline
just didn't give them the performance they needed. (But then it would
have been more profitable in the long run to fix the _compiler_.)

> Usually the
> control structures are so small (within a single subprogram), that even
> if you *only* used goto for control flow (which I don't recommend, of
> course!) you could still understand the program.

Hmm, I'm not sure what else you'd use goto for if not "control flow",
but perhaps you just mean "_local_ control flow" within a very small
procedure, as opposed to large-scale spaghetti code (which I'm sure
nobody is advocating).

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------