GOTO Considered ...

GOTO Considered ...

[Al Christians]

I have seen one application in which the GOTO statement worked very
well.  The program was a game (text mode, circa 1980) that depicted the
movement of an adventurer through a castle of many chambers.  I was
helping an adolescent who was born after I started programming try to
learn something about propitious techniques for writing software.

Well in that genre, which was very popular amongst people of that age
programming Basic in that era,  the GOTO could be part of a very
well-designed program.  When you went to a chamber of the castle, it
didn't matter where you went there from -- there was no need to ever
RETURN or even to GOBACK.  The program made heavy use of GOTO's, but it
met my definition of well-structured, i.e. the structure of the program
was obviously in accord with the structure of the problem.

This didn't get me to love the GOTO -- I doubt that I've written as many
GOTO's since then as that one program contained.  But, that little kid's
code convinced me that any programming language feature, no matter how
inherently worthless, is likely to be wonderful when used correctly in
the correct situation.  (I'll even allow that a Fortran kind of guy
might have solved the same problem just as elegantly with an FSM using
one or more computed GOTO's)

Al

Re: GOTO Considered ...

[Adam Beneschan]

In article <dewar.866202982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 >I think a lot of the difficulty is that many programmers don't like
 >the look of a GOTO at the syntactic level. What one should be
 >allergic to is the misuse of goto's, but that of course requires a
 >more sophisticated level of judgment.  Much easier to understand a
 >simple rule like "goto's are horrible, period".
 >
 >I once consulted for a big aerospace company on some big COBOL code,
 >which was very hard to read. In one place there was something like:
 >
 >    PERFORM CLOSE-FILES.
 >
 >and I had a very hard time understanding what could happen when control
 >returned from the PERFORM (which for the purposes of this discussion can 
 >be considered comparable to a procedure call).
 >
 >After following the logic down ten levels, I found a STOP RUN statement,
 >so in fact the upper nine levels of PERFORM never did return at all.
 >
 >I commented that the code would be MUCH clearer if those PERFORM statements
 >were replaced by GOTO statements. The response
 >
 >"Oh, but we aren't allowed to use GOTO statements"

Sigh . . . I think anyone who institutes a no-GOTO rule in a COBOL
environment ought to have their head examined.  I was working as a
COBOL programmer about 20 years ago, when "structured programming" was
just coming into vogue, and I tried to write all my COBOL programs
without using any GOTO's.  I finally gave up.  COBOL doesn't have any
loop constructs---you have to put the body of the loop somewhere else
and do a PERFORM UNTIL or something.  Also, COBOL doesn't have the
begin..end or if..end if constructs that languages like Algol and Ada
have, so that something like

      if condition_1 then
          statement_1;
          statement_2;
          if condition_2 then
              statement_3;
          end if;
          statement_4;
      end if;

could not be coded directly in COBOL, without using a PERFORM.  While
I could accomplish GOTO-less programming by using lots of PERFORMS,
the PERFORM'ed "procedures" didn't really match what a procedure
should be, a cohesive module that performs a specific task on given
inputs and outputs.  These "procedures" were just there to get around
a lame language syntax.  What I found was that using this many
PERFORMS actually detracted from readability, and that I could make my
code more readable to use GOTO's for control structures such as these,
while keeping my "procedures" small and with well-defined purposes,
and keeping to the "structured design" principles that Yourdon had
written about.  (And, of course, avoiding mutant constructs like ALTER
and like overlapping procedures that you could call in different ways
by changing the names of the paragraphs you PERFORM'ed THRU.)

Well, enough nostalgia for one day . . . (P.S. If COBOL has been
modified to provide these control structures it used to lack, I'll
retract my initial statement.)

                                -- Adam

Re: GOTO Considered ...

[Robert Dewar]

Adam's comments about COBOL, e.g.

<<Sigh . . . I think anyone who institutes a no-GOTO rule in a COBOL
environment ought to have their head examined.  I was working as a
COBOL programmer about 20 years ago, when "structured programming" was
just coming into vogue, and I tried to write all my COBOL programs
without using any GOTO's.  I finally gave up.  COBOL doesn't have any
loop constructs---you have to put the body of the loop somewhere else>>


Are complete nonsense. He is talking about COBOL-66 (some of his comments do
not apply to COBOL-74, and none of them apply to the current standard, which
dates from the early 80's, and will soon be replaced by a remarkably
sophisticated object oriented version of the language).

We complain when people assume that Ada means Ada 83, and frame their
comments on this language in terms of this obsolete standard, so please
let's not make the mistake of doing even worse violence to other languages.

In fact, having written an extensive amount of COBOL 74 (I wrote large
sections of a COBOL compiler, the current Computer Associates Realia COBOL
compiler for the PC, and this compiler was written entirely in COBOL), my
experience is that I found the need for GOTO's in COBOL 74 to be entirely
comparable to the need in Ada 95. Sam's article could perfectly well be
rewritten to apply to COBOL!

Robert


Incidentally, looking at the loop issue specifically. COBOL certainly does
have full nesting of typical looping constructs, but it does also allow
the simple abstraction my means of PERFORM, as in

Process-Year.
  perform Process-Month varying Month from Jan to Dec.

Process-Month.
  ...


I find this kind of abstraction very handy, and miss it in the Algol syle
languages such as Ada. The only way to get such abstraction in Ada is to
declare a procedure, but

(a) this is FAR heavier syntactically, look at the light syntax in COBOL
    for these kind of abstraction procedures, just the name of the procedure
    and two periods, and that is it!

(b) the requirement that you declare procedures before you use them is in
    this case a serious impediment, because it means you introduce detail
    before the big picture. It is what results in the complaint in Pascal
    that you have to read the program backwards. In Ada you can get around
    this by using separately compiled units, but that is even heavier and
    more inappropriate for this kind of local procedural abstraction.

Of course if you have never written in a language that allows this kind of
procedural abstraction (COBOL is the most familiar such language, but there
have been others, including SETL, CDL and ABC), then you probably don't miss
it. Certainly you do not see Ada/C/etc programmers using this kind of
abstraction. Instead they tend to nest control structures deeply.

COBOL programmers generally have the same disgust towards heavy nesting
of control structures that anti-goto people display towards gotos in Ada :-)
They find heavy nesting confusing and avoid it using Perform abstraction:

Process-Balance.
   if Balance is negative then
      peform Send-Bill
   else
      perform Register-Credit
   end-if.

Send-Bill.
   ...


Register-Credit.
   ...


And, in case Adam or someone else is remembering COBOL from ancient
historical experience, it is of course the case that COBOL has full
syntactic capabilities for nested control structures, fully comparable
to those in Ada or C, and in some ways superior, but people just do not
like heavy nesting very much anyway.

So, COBOL in the Ada group, irrelevant junk? I think not. In the Ada
community, we find it frustrating that people dismiss Ada without knowing
anything about it. So, as I asked before, let's be especially careful not
to do that ourselves. In particular, I often notice the tendency to trash
C and C++ without knowing enough of the technical details. Yes, there are
significant and well founded technical arguments for the superiority of
Ada over C and C++, but badly informed arguments are unhelpful. It is one
thing to poke fun at C in "The Maiden and the Mandate (*)", but quite
another to present bogus technical arguments.

Sometimes when I read these uninformed attacks on other languages, I feel
like Lindsey Brigman in "The Abyss", who, having just encountered the aliens,
gets immediate support from a UFO nut, and angrily says to him "Get off my
side!"

Robert Dewar

(*) We recently performed TM&M in London (a successful performance, which
was attended by Ada's great great grandson :-) We will put the full script
of M&M on our web site in the near future, along with some clips from the
production.

Now we can get busy with the next chapter in "Musical Adventures of Lady
Ada", which will be a performance at the next Tri-Ada in St Louis. The
title of this show is "Princess Ada or the Castle AdaMandate". Make your
plans to come now (tell your boss how critical it is that you attend the
show to sharpen your Ada skills, and see all the latest Ada stuff, ACT
will certainly be there with lots of nice new Ada stuff, and I am sure
our competitors will also have lots to show also :-) And then come and
see the show :-)