Re: GOTO considered necessary (reworked)

["John G. Volan" <johnvolan@sprintmail.com>]

Robert Dewar wrote:
> 
> Jeff Carter responded to Sam's article with a typical bunch of dogmatic
> never-use-gotos stuff that smacks of the fanaticism that was popular in
> the 70's, but I would have hoped had disappeared by now.

Funny, I read the same post and didn't come away with that impression at
all. Sounded like Jeff was voicing some reasonable concerns about the
dangers of gotos and their impact on maintainability.  (In fact, Jeff
was mostly just agreeing with some counter-arguments that Sam Mize
himself enumerated.)

> Anyway Sam, take this as a vote from me that your treatment is very nice,
> and just at the right level of dont-use-goto-except-where-useful.

I agree with that philosophy, but I'd clarify it: Gotos may be used only
as a _last_ resort, after every other possible structure has been
exhaustively tried and still found to be less understandable, or
maintainable, or efficient, or whatever, than the proposed goto
solution.  But this is a very stringent requirement, and I expect it
will be very rare that a goto solution will beat out all other
alternatives.

> I particularly object to Jeff's notion that introducing miscellaneous
> boolean flags to replace structured use of gotos (like the CONTINUE)
> makes code more readable. 

Where did Jeff say anything about extra Booleans? His point seemed to be
merely that the effect of a goto can often be achieved by abstracting an
operation out as a subprogram with one or more premature return
statements, and that this may be less prone to maintenance errors than
gotos.  For instance, Sam Mize's example of insertion would clearly be
better off as a procedure:

  Items : array (Positive range Lo .. Hi) of Item_Type;
  Last  : Natural := Items'First-1;
  ...
  procedure Insert (New_Item : in Item_Type) is
  begin
    for I in Items'First .. Last loop
      if Items(I) >= New_Item then
        -- item at index I is successor for New_Item,
        -- so move items starting from I forward and
        -- insert New_Item in front of them
        Items(I+1 .. Last+1) := Items(I .. Last);
        Items(I) := New_Item;
        Last := Last + 1;
        return; -- "premature" return
      end if;
    end loop;
    -- New_Item is greater than all Items, append onto end
    Last := Last + 1;
    Items(Last) := New_Item;
  end Insert;

I would rather trust a compiler to optimize this via pragma Inline
rather than rely on manual optimization using gotos.

> Far from it in my opinion, The use of Boolean's
> to encode state that is more reasonably and clearly encoded in the program
> counter is a big mistake in my opinion, and can often severely damage
> readability in these rare cases we are talking about.

Agreed. And agreed that these cases would be rare. (So far the only case
that I find compelling are FSAs.)  But in the procedure example above,
where pray tell are the alleged extra Booleans?  Isn't the state being
encoded in the program counter, by virtue of where the return from
procedure occurs?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@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? :-) ");
------------------------------------------------------------------------