Another reason for goto

Another reason for goto

[Marc.Graham]

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
                   

Re: Ada and the infamous goto

[William Thomas Wolfe,2847,]

From a recent article by blakemor@software.ORG.UUCP (Alex Blakemore):
>    According to John Barnes [Programming in Ada p. 61]
>      "The main reason concerns automatically generated programs ...
>      [to] transliterate (by hand or machine) a program from some other
>      language into Ada"
>      He also points out the syntax was deliberately made
>      to stick out like a sore thumb.  <<UGLY_LABEL>>

   From what I've heard, as recently as October's Tri-Ada '88,
   automatic translation is pretty well discredited as a software
   porting technique.  The Ada Adoption Handbook (Foreman and Goodenough,
   May 1987) summarizes: "language translation must be viewed as a risky,
   short-term proposition which will yield results of unknown quality.
   Redesigning and recoding the system in Ada or interfacing newly written
   Ada code with the current implementation are much preferred approaches.".

   The basic problem is that when one translates Fortran into Ada with
   an automatic translator, what one gets is Fortranized Ada, with
   (you guessed it...) gotos everywhere.  Other problems (Ada IC Newsletter,
   September 1988) include the lack of software engineering practices in
   the old code, and the fact that automatically translated programs often
   exhibit large timing changes (~ 50% of the efficiency of the old program). 

   Richard Waychoff, who participated in the development of the Fortran-to-Ada
   and COBOL-to-Ada translators which now reside in the Ada Software 
   Repository, was quoted as saying: "The code was not pretty and it was 
   not efficient... my guess is that the translators were never used
   [on the project for which they were originally built].".


From article <8901171823.AA20919@bx.sei.cmu.edu>, by Marc.Graham@SEI.CMU.EDU:
> 
> 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.

   Actually, a Boolean could be used to do this as well, but a 
   better solution would be to add a cycle statement.

> 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. 

     How about:

        INPUT_LOOP: loop

                       -- prompt the user

                       -- get the user's input

                       exit INPUT_LOOP when INPUT_OK;
   
                       -- inform user of reason input is invalid, 
                       --   or at least BEEP the user's terminal.

                    end loop;


     There really *is* a loop here...  

Re: Ada and the infamous goto

[Bob Hathaway]

>
>   Speaking of the non-goto rationale behind Ada, can anyone tell me
>   why Ada has a goto statement??  (See LRM 5.9...)  The Rationale for 
>   the Design of Ada conveniently fails to discuss it.

Modula-2 doesn't have a goto statement and I've never missed it.
I recommend removing the goto in Ada also.   There is no high-order
justification and goto's complicate code generation and optimization.

Bob Hathaway
rjh@purdue.edu

Re: Another reason for goto

[William A. Bralick]

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

Re: Another reason for goto

[Stephe Leake]

In article <820@afit-ab.arpa> wbralick@afit-ab.arpa (William A. Bralick) writes:

   ...

   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.

Ada can be either a High level language, _or_ a low-level one. Why
should I abandon strong typing just because I need to do something
fast? If I need a fast subroutine, I write it in "low-level" ada; no
tasks, exceptions, etc; I would feel free to use a goto (although I
have yet to see a need for one). In fact, in Ada I can use single
precision, which can often cut execution in half!

Lets not limit ourselves by arbitrary notions that _all_ Ada code must
be high-level and abstract.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Another reason for goto

[William Thomas Wolfe,2847,]

From article <849@primus.cme.nbs.gov>, by leake@cme.nbs.gov (Stephe Leake):
> 
> If I need a fast subroutine, I write it in "low-level" ada; no
> tasks, exceptions, etc; I would feel free to use a goto (although I
> have yet to see a need for one). 

     Tremblay and Sorenson summarize:

        A common thought among proponents of the GOTO is: "I just
        might need it; something might come up."  The answer to this
        appears to be: "Nothing ever does." 



                                       Bill Wolfe

                                wtwolfe@hubcap.clemson.edu

Re: Another reason for goto

[Stephe Leake]

What does it actually _cost_ us to have goto in the language? If you
never use it, the only cost is the paragraph or so in the LRM, and
some code (never executed) in the compiler. For such a small cost, why
should we bother removing it?

I know of one CASE tool that generates Ada code, with lots of goto's.
Yes, you would not code it that way if you were writing Ada directly,
but that's the point of a CASE tool; it gives you a different
(hopefully better/more productive/more readable) way to write code.
Personally, I prefer Ada, but I do not want to discourage work on
better CASE tools.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899