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.1 required=5.0 tests=BAYES_20,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!SEI.CMU.EDU!Marc.Graham
From: Marc.Graham@SEI.CMU.EDU
Newsgroups: comp.lang.ada
Subject: Another reason for goto
Message-ID: <8901171823.AA20919@bx.sei.cmu.edu>
Date: 17 Jan 89 18:23:47 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>


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. To simulate it, one
issues a goto a <<label>> on a null; which is the final statement in the
loop block being continued.

Also, consider the case of input editing in a situation in which, if
the input does not pass the edit, it will be reacquired until the
input is good. Without goto one writes this as

loop
   -- get input
   case input
     when good_alt_1 =>
                   . . .
                   exit;
     when good_alt_2 =>
                   . . .
                   exit;
     .
     .
     .
     when others => null;
   end case;
end loop;

Even though I do that myself, I can't help thinking that its wrong.
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. More importantly, it more nearly captures the
essence of what's going on (in my opinion, which is rarely humble).

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.

Marc H. Graham                    Software Engineering Institute
marc@sei.cmu.edu                  Carnegie Mellon University
(412) 268 7784                    Pittsburgh, PA   15213