Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!haven!udel!mmdf
From: tweten@gilmore.nas.nasa.gov (Dave Tweten)
Newsgroups: comp.os.minix
Subject: Re: gotos
Message-ID: <24984@louie.udel.EDU>
Date: 3 Oct 89 20:04:14 GMT
Sender: mmdf@udel.EDU
Lines: 103

I hesitated before sending my original message on this issue because of
its potential for triggering more religious heat than intelectual
light.  I've been pleasantly surprised at the ratio of light to heat in
the responses, which has encouraged me to write my second and last
comment on the topic.

Several apparent believers in the "no gotos" faith responded to the
effect that in their experience "goto" had never been necessary to
express an algorithm; they had each gone for some long period of time
without ever having written one.  I agree.  It IS never necessary.  Any
algorithm can be expressed in C, using only linear code, "while" and
functions.  The rest of the control structures in the language,
including "goto", serve only to increase efficiency, clarity and
maintainability.

What is programming?  Clearly, I don't believe it is a religion.  In
spite of my job title, I don't believe it is science.  It is more
humanistic than mere mathematics.  It is more mundane than art (Donald
Knuth notwithstanding).  I prefer the notion of programming as craft,
with a shade of meaning somewhere between that of the AFL/CIO and of
the Actors Guild.  As a good craftsman, it is my responsibility to
possess and to know how to use a wide variety of tools of my trade.  I
must know their powers and their dangers.  I must know when the tool
fits the problem and when it doesn't.

Several respondents adequately covered the uses of "goto" which amount
to a multi-level "break".  What follows is an explanation of why I think
"goto" works well for the third example in my original message, breaking
out of a single loop without executing the loop exhaustion code.  The
"gotofull" form is:

		while (<still looking>) {
			<do stuff>
			if (<we found it>) {
				<do foundit stuff>
				goto the_end;
			}
			<maybe do more stuff>
		}
		<do couldn't find it stuff>
	the_end:;

An obvious "gotoless" alternative is:

		while (<still looking>) {
			<do stuff>
			if (<we found it>) {
				<do foundit stuff>
				break;
			}
			<maybe do more stuff>
		}
		if (! <still looking>) {
			<do couldn't find it stuff>
		}

I prefer the form with the "goto", primarily for maintainability
reasons.  Introduction of extra condition tests increases the chance of
error and the difficulty of code analysis.  It becomes possible not
just to get it wrong, but also to get it inconsistent.  To my taste,
the second form is also less readable than the first.

Now, one could wrap the whole construct in a function and use an
embedded "return" statement, but that would be cheating.  Many of the
faithful regard imbedded returns as being equivalent to gotos and
exactly as sinful.  I agree.  Besides, except in the case of code which
should be set apart, either because it is a local option or because it
is in another language, I generally prefer not to write a function
unless it will be called from at least two places.

Dr. Tanenbaum's response was amusing.

From: Andy Tanenbaum <ast%CS.VU.NL@VM1.NoDak.EDU>

	I'll bet you like
	
	    i = 0;
	     <<VAX
	      some VAX assembly statements
	         XAV>>
	     j=0;
	     more C
	
While project leader for CDC's Cyber 200 FORTRAN '77 compiler and
library project (Fortran 200), I argued loudly (if unsuccessfully) that
in-line assembly code should not be carried over from the predecessor
FORTRAN '66 compiler.  I maintained that "Q8" in-line syntax converted
a good compiler into a bad assembler.  There is no doubt in my mind
that assembly code is occasionally the correct tool for the job.  The
"portable" way to use assembly code is to write separate assembler
source files.  That way a simple examination of the source file
directories will show what has to be rewritten for a new machine.  By
contrast, when there is in-line assembly a line-by-line examination of
all source files becomes necessary.

Incidently, try this for a REAL bit of heresy.  That project at CDC
offered me the second situation of only two in my 16-year programming
career in which instruction modification was the best tool for the job.
It was also the first in which my management permitted me to use it.
If you have it available, check the source code for FORTRAN 200's
"index" function in the case of a one-character pattern string.

But then, programming really ISN'T a religion, is it?