Re: GOTO considered necessary (reworked)

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <33A58C79.1C7A@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> 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...