From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99222a5bd46ef3c9 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: GOTO considered necessary (reworked) Date: 1997/06/16 Message-ID: #1/1 X-Deja-AN: 248911950 References: <5nn2fm$11dk$1@prime.imagin.net> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-06-16T00:00:00+00:00 List-Id: In article , Robert Dewar 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