From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99222a5bd46ef3c9 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: GOTO considered necessary (reworked) Date: 1997/06/16 Message-ID: <33A58C79.1C7A@sprintmail.com> X-Deja-AN: 248880104 References: <5nn2fm$11dk$1@prime.imagin.net> <199706121410.QAA05823@basement.replay.com> <33A0840B.1B41@sprintmail.com> Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-06-16T00:00:00+00:00 List-Id: Robert A Duff wrote: > > In article <33A0840B.1B41@sprintmail.com>, > John G. Volan 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? :-) "); ------------------------------------------------------------------------