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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: GOTO considered necessary (reworked) Date: 1997/06/17 Message-ID: X-Deja-AN: 248944073 References: <5nn2fm$11dk$1@prime.imagin.net> <199706121410.QAA05823@basement.replay.com> <33A0840B.1B41@sprintmail.com> <33A58C79.1C7A@sprintmail.com> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada Date: 1997-06-17T00:00:00+00:00 List-Id: In article <33A58C79.1C7A@sprintmail.com> "John G. Volan" writes: > 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. Stop right there! A web of sequences ended by gotos is the structure of a finite state machine. It is not a simulation or substitute for the "real" structure, it IS the real structure. Proof by example: ten years ago most computers were finite state machines. What was the primary control structure? End of discussion. (Well, being a nit-picker from way back I can't leave it at that. First, the reason I said "most computers" and "ten years ago" is that most CPUs today are not finite state machines, they emulate FSMs! Usually the hardware manual has a long chapter about when you can count on which properties of the simulation holding. But the times when all of a modern CPU is in any defined state are few and far between. Second, there are a few computers around which have tried different models. Data flow architectures never became popular as APIs, but some computer chips use a dataflow model, and emulate a FSM for the API.) > 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. ROTFL! It does take lots of misdirected vigilence to prevent fall-through. Of course, most tools for building FSMs spend a great deal of effort restructuring the tables to MAXIMIZE the amount of space conserved by such techniques. And anyone who builds a non-trivial FSM without tool support needs their head examined. (Hmmm. Better clarify that...I have built several non-trivial FSMs using rudimentary tool support, but that support, mapping states in the final machine back to the orginal grammar is crucial. Without that formal verification support, you spend more time chasing your tail than programming. It is always worth building those tools.) > 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... The right tool is not the compiler, or at least not the Ada compiler. There are lots of tools for building FSMs from grammars, non-deterministic FSMs and regular expressions. I spent over four year supporting and enhancing one such tool. Some of them make Ada compilers look like simple tools. But believe me, they put the gotos in the right place, even when it would take you years by hand to figure out that that was the right place. For instance the tool mentioned above, LALR on Multics would accept all LALR(k) grammars (and some non-context free but right-regular grammars) and produce tables which implemented a non-context free grammar equivalent to but much smaller than the original grammar. > -- 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. Why should the compiler be the only tool that has a hand in converting your design into machine code? There are many projects where the non-compiler tools used in producing the final product make a much larger contribution than the compilers. How to measure such things? Computer cycles burned? Wall-clock time? Function points? In any case, I have worked on building compilers, and there the SLOC count for actual sources is a good measure. I have worked on compiler projects where the compiler, linker, and run-time accounted for less than a third of the total source code, and of course, a lot of that source was not in Ada or even PL/I, but in various tool defined languages. Even if you have never worked on a compiler, take a look at Motif UIL or the output of some screen generator programs. When such tools generate high-level code for FSMs, gotos ARE the right abstraction. Incidently, I chided Mike Brenner for putting too much emphasis on the efficiency issue. Correctness is of equal or higher importance and the clarity form using gotos WHERE APPROPRIATE is a huge contributor to correctness. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...