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=-0.5 required=5.0 tests=BAYES_00,INVALID_MSGID, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,ec4cde5d799065b6 X-Google-Attributes: gid103376,public From: John G. Volan Subject: Re: Is there an ADA analogue to the C++ continue statement? Date: 1997/09/29 Message-ID: <875552739.30613@dejanews.com>#1/1 X-Deja-AN: 276457884 References: <01bcc32e$350b5ba0$6409868b@gateway> <5vqm61$fu2$1@cf01.edf.fr> X-Http-User-Agent: Mozilla/3.0 (WinNT; I) X-Originating-IP-Addr: 192.94.94.61 (gatekeep.ti.com) proxy [1.0 gatekeep.ti.com:80 (Squid/1.1.15)] for client [204.31.91.21] Organization: Deja News Posting Service X-Authenticated-Sender: John G. Volan X-Article-Creation-Date: Mon Sep 29 17:05:40 1997 GMT Newsgroups: comp.lang.ada Date: 1997-09-29T00:00:00+00:00 List-Id: Robert Dewar wrote: > > The most reasonable translation [of continue] > is to introduce a very stylized use of > the goto for this purpose, putting a label <> just before the > end loop, and then doing a goto to get the effect you want. So we would > have: > > while Condition_1 loop > statement_1; > > if Condition_2 then > goto Continue; > end if; > > statement_3; > > <> > end loop; One difficulty with this: If you have more than one loop within the same scope which needs to work this way, then you will encounter a name clash unless you come up with a different label-name for each loop, e.g.: while Condition_1 loop statement_1; if Condition_2 then goto Continue_1; end if; statement_3; <> null; -- note: a goto-label has to have a statement to hang on end loop; while Condition_3 loop statement_4; if Condition_4 then goto Continue_2; end if; statement_5; <> null; -- note: a goto-label has to have a statement to hang on end loop; This might be a nuissance for some people, just as it would be a nuissance if we were still living in the age of assembly, where even simple if-statements required uniquely-named labels. Then again this could have been worse: If Ada�s rules regarding goto were more liberal, the practice Robert suggests could have been a source of bizarre bugs that might have arisen from simple typographical errors: while Condition_1 loop statement_1; if Condition_2 then goto Continue_1; end if; statement_3; <> null; end loop; while Condition_3 loop statement_4; if Condition_4 then goto Continue_1; -- Oops! end if; statement_5; <> null; end loop; Luckily, this is illegal. (GNAT generates the error message �target of goto statement is not reachable�.) > Final note: for Ada programmers who are incurably goto-challenged, you can > achieve exactly the same effect as the above loop by using: > > while Condition_1 loop > declare > Continue : exception; > begin > statement_1; > > if Condition_2 then > raise Continue; > end if; > > statement_3; > > exception > when Continue => null; end; -- need one of these here > end loop; > > A kind compiler will translate this use of exceptions into a simple goto > and bypass the normal exception mechanism. Why anyone would go to such > circumlocutions escapes me, but some programmers will do almost anything > to avoid the goto keyword, and besides there are silly coding standards > around which totally forbid the use of the goto keyword. This scheme avoids the name clash I described above, but there are coding standards that would consider declaring, raising, and handling an exception all within the same scope to be just as "naughty" as using a goto. The argument is that an exception should represent part of the interface of an abstraction, not part of its internal logic. Basically, an exception should represent an error situation which the given abstraction is able to _detect_, but which, by deliberate design, it is not able to _handle_, because the policy for handling this situation is beyond its chosen level of abstraction. Raising and propagating the exception out of the abstraction leaves it up to its clients to decide the proper policy. Otherwise, if the condition is just a "normal" situation anticipated by the internal logic of the abstraction, then "normal" control-flow constructs (it is felt) should be good enough. I agree with Robert that resorting to a goto under these circumstances is more reasonable and "honest" than "faking" a goto with an exception. But I would tend to avoid the goto as well, and just live with the extra level of nesting: while Condition_1 loop statement_1; if not Condition_2 then statement_3; end if; end loop; while Condition_3 loop statement_4; if not Condition_4 then statement_5; end if; end loop; -- Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Raytheon/TI Advanced C3I Systems, San Jose, CA", Work_Email => "jvolan@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) "); -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet