Re: GOTO considered necessary (reworked)

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

Michael Brenner says

<<Comment: section 3 (b) on efficiency should be moved up to being
the primary reason for using GOTOs in FSAs, other posts notwithstanding.>>

I agree that few (but not no) compilers will be able to convert the canonical
case/state formulation to the formulation with jumps, so it is certainly
reasonable to cite the efficiency argument.

Still I think the cases in which one should let efficiency dominate stylistic
considerations are very rare. To do this other than in cases where you really
KNOW that the efficiency is that critical seems to be to be premature
optimization. In addition, the general approach of trying to outguess an
optimizing compiler often leads people to do quite counterproductive things.

Within broad boundaries, I think the best approach is to write in the
clearest way possible, and then, if there is an efficiency problem, examine
ways to improve the code.

I say within broad boundaries, because one needs to have a reasonable feel
for gross levels of efficiency. For example, I sometimes see Ada 95 
programs where controlled types have been used with complete abandon and
obvious obliviousness to the fundamental inefficiencies that result.

But I would seldom chose between ways of doing things on an efficiency
basis, and I certainly would not do so in this case. I would use the
goto approach because I think it is clearer, even if it was less efficient,
unless I found that it made a critical efficiency difference.

Obviously if you do not share the quite common view that the goto
representation of FSM's (i.e. encoding the state in the code location)
is clearer, then you will think that efficiency is the concern, but to
elevate efficiency as the primary motive in this document would be quite
misleading, since it would miss the point that the FSM case is one of 
those rare cases where a significant number of people *do* consider
that the goto representation is clearer.