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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!afit-ab!wbralick
From: wbralick@afit-ab.arpa (William A. Bralick)
Newsgroups: comp.lang.ada
Subject: Re: Another reason for goto
Message-ID: <820@afit-ab.arpa>
Date: 18 Jan 89 04:43:54 GMT
References: <8901171823.AA20919@bx.sei.cmu.edu>
Reply-To: wbralick@blackbird.afit.af.mil (William A. Bralick)
Distribution: na
Organization: Air Force Institute of Technology; WPAFB, OH
List-Id: <comp.lang.ada>

In article <8901171823.AA20919@bx.sei.cmu.edu> Marc.Graham@SEI.CMU.EDU writes:
)
)Ada does not have a `continue' or `abandon' statement for loop
)control. Such a statement is orthogonal in some sense to exit. One
)uses it in the body of a loop when one wishes to terminate this
)iteration of the loop and start on the next one.

This sounds like a rather exceptional case ... :-)

)To simulate it, one
)issues a goto a <<label>> on a null; which is the final statement in the
)loop block being continued.
)
) [loop example implementation deleted to conserve bandwidth]
)
)There really isn't a loop here, in some sense. Good input is
)processed; bad input is rejected. The thing looks better as
)
)<<get_in>>
)    -- get input
)    case input
)     when good_alt_1 =>
)                   . . .
)     when good_alt_2 =>
)                   . . .
)     .
)     .
)     .
)     when others => goto <<get_in>>;
)   end case;
)
)This should occupy a hair's breadth less space and consume a hare's
)breath less time.

This sort of concern with micro-efficiency is only warranted if you have
identified this section of code as being part of the 20% wherein your
program spends 80% of its time, otherwise it is inappropriate.

) More importantly, it more nearly captures the
)essence of what's going on (in my opinion, which is rarely humble).

I disagree, you have a classic "loop until good input" situation here.
It can be directly implemented as follows:

loop

   begin

      --  get input

      case input is

         when good_alt_1 =>  do_alt_1_stuff;
         when good_alt_2 =>  do_alt_2_stuff;
         ...
         when good_alt_n =>  do_alt_n_stuff;

         when others     =>  null;  -- this handles a legal, but undesirable
                                    -- input, alternatively, you could do
                                    -- something with all the rest of the cases.
      end case;

      exit;

   exception

      when  DATA_ERROR  =>  handle_it; -- this handles the truly "bad" input

   end;

end loop;
   

The exception exists to handle the kind of situation that you are
apparently trying to address with the goto.  Why not use it?
(See section 14.7 of your LRM for another example.)

)
)Good code is not the result of a mindless policy of goto removal; bad
)code is not the result of a sensible policy of goto insertion.

However, I have yet to see a case where the goto is *necessary*  It is
a direct tweek at the program counter and is generally at too low a 
level of abstraction for a HOL.  If time (and space) are that critical
in a given section of code you should "goto" C (using pragma interface)
or assembler if absolutely necessary.

Regards,
-- 
Will Bralick : wbralick@afit-ab.arpa  |  If we desire to defeat the enemy,
Air Force Institute of Technology,    |  we must proportion our efforts to 
                                      |  his powers of resistance.
with disclaimer;  use disclaimer;     |               - Carl von Clauswitz