Re: GOTO considered necessary (reworked)

[bobduff@world.std.com (Robert A Duff)]

In article <dewar.866304502@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>No, but we do know, without statistics, that some Ada programmers regard 
>goto's as evil, and go through nasty contortions to avoid them. So Sam's
>very reasonable position statement is not completely irrelevant, if it
>convinces even one of these anti-goto fanatics to moderate their position,
>that is useful.

True, although even the fanatic won't produce *horrible* code.  OK, the
fanatic will introduce some extra boolean flags here and there, and
otherwise damage the code, but not by a lot.  Whenever somebody posts
some code that is claimed to desperately need a goto, the anti-goto
fanatics can produce similar code that doesn't use goto.  And we can
have endless arguments about whether the goto-less version is better --
this is because the goto-full and goto-less versions tend to be very
*similar* in terms of readability, maintainability, etc.  Because people
disagree about a particular program (whether or not it should contain a
goto), I claim that the readability difference can't be huge -- if it
were huge, it would be obvious to all.

>However, there are some useful points here that apply more widely. Machine
>generated code that will not be looked at by people can have all the gotos
>it likes (Sam covers this point). This is of course obvious to anyone with
>the slightest sense. BUT, I know at least one case in which a perfectly
>reasonable tool was rejected because the Ada it output did not meet
>corporate standards (which had a silly zero-tolerance position on gotos).

Yes, I agree.  I've even seen some people claim that goto can't be any
better than 'if' and 'case' and 'loop', since those are all transated
into gotos at the machine level anyway!

>Yes, among reasonable people, we have a reasonable consensus that style
>issues are almost never absolute, and that it is a BAD THING to convert
>recomendations into hard clad rules, and in particular, to convert rules
>that say "minimize the use of X", to "avoid the use of X". But in the
>real world, there are plenty of nitwits around writing style manuals
>who do exactly that.

Good point.

>I have several times now run into people saying that they were forced to
>code in C in situation XXX. Incredulous, I query them, and suggest that
>they could perfectly well do that in Ada using Unchecked_Conversion.
>"Oh, they say, we can't use UC, it's forbidden by our coding conventions."
>
>Then when I complain that that is a silly idea, they follow up with
>
>"But UC is potentially implementation dependent, we are required to write
>portable code"
>
>Of course their criterion for beautiful guaranteed implementation dependent
>code in C is that it passes at least some execution tests on the platform
>they happen to be running on!

Yes, I've heard such nonsense, too.  Of course U_C is a bit different --
if you need it, and don't have it, it's not easy to work around.  Goto,
on the other hand, has easy workarounds.

>(note for example, Joe Gwinn's repeated claim that you can manage IO mapped
>memory in C. Totally bogus of course, there is nothing in the ANSI standard
>for C that assures you of this -- what is true of both C and Ada is that
>in practice, given reasonable assmptions, you can handle memory mapped
>IO, even though there is no guarantee from the language that it will work.

I'm still waiting to see the C.  ;-)

- Bob