Re: GOTO considered necessary (reworked)

[dewar@merv.cs.nyu.edu (Robert Dewar)]

John Volan said

<<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.
>>

First, to me, the mapping of states into sections of code, and the mapping
of transitions as gotos, seems pretty direct -- direct enough that I do not
think it would make sense to dream up some syntactic gizmo -- although as
Robert Eachus points out, a preprocessor can very well provide the equivalent
of this syntactic gizmo.

As for fall through, that is quite a bogus argument. If you map a FSM into
a loop/case structure with an explicit state variable, then you have to be
equally careful not to forget to modify the state variable. The error in one
case is accidental transition to the following state, the error in the other
is an infinite loop in one state -- not much to call there.


Of course in practice, one of the advantages of the goto model is that in
some cases, it is quite natural to fall through to the following state:

   <<Sign>>
      code to acquire sign

   <<Digits>>
      code to acquire digit
      ..

      if Another_Digit then
	 goto Digits;
      else
	 goto Exponent;
      end if;

or somesuch, where Sign does fall through to Digits. I find this quite
readable, and code of this kind can be found in many lexical analyzers
in compilers.

yes, of course you can often replace a specific instance (like the one above
if that is all there is to it), with a simpler structure (e.g. a loop for
the Digits above).

The time that a goto threaded structure becomes appropriate is when you have
a very involved FSM with many intertwined transitions.

Basically an FSM of this kind *fundamentally* corresponds to spaghetti code,
in that the states are executed in some non-structured sequence depending on
the input, and therfore cannot be arranged into neat structures.

We have only two methods of handling such spaghetti sequences in typical
PL's, the code+goto representation, or the loop-case representation. One
might say that neither is perfectly happy, and that is right, since the
underlying sequence of control is in some sense unhappy. But given this
choice I prefer the code+goto representation.

As Robert Eachus notes, for a complex FSM, there is considerable merit in
using one of the standard tools to generate the code.