Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!jfr
From: jfr@locus.com (Jon Rosen)
Newsgroups: comp.lang.pascal
Subject: Re: Gotos are ok (Was Re: IMPLEMENT GOTO ACROSS MODULES IN TURBO PASCAL??)
Message-ID: <21489@oolong.la.locus.com>
Date: 24 Jan 91 17:38:35 GMT
References: <2802@oucsace.cs.OHIOU.EDU> <1991Jan21.134342@cs.utwente.nl> <2427@bnlux0.bnl.gov>
Organization: Locus Computing Corp, Los Angeles
Lines: 77

In article <2427@bnlux0.bnl.gov> kushmer@bnlux0.bnl.gov (christopher kushmerick) writes:
>In article <1991Jan21.134342@cs.utwente.nl> devisser@cs.utwente.nl (Jan de Visser) writes:
><stuff deleted>
>Except for the fact that an exit is just a fancy way of spelling goto, with the
>effective label being a automatic label right before the ultimate end. (I do
>not know if this is how it is actualy implemented, it may be a return, but
>from a logical viewpoint, this is what it is.)
>
>I like to use gotos within programming blocks, but not between programming
>blocks, by programming block, I mean a begin-end pair.
>
>I also do like the exit construct mentioned above, but I understand that it is
>a goto.
>
As in any religious discussion, people have a way of misstating (or
misunderstanding) the reality... EXIT (insert any other exit-type
construct: LEAVE, BREAK, RETURN...) is NOT simply a misspelled GOTO...
The difference between EXIT/LEAVE/etc and GOTO is that EXIT/LEAVE/...
can ONLY goto to a SINGLE place... I.e., in the abstract, the programmer
can't make a mistake... 
 
In the following pseudo-code:
   
   Repeat...
    ...
    if ... then leave;  
    ...
   EndRepeat;
   
There is only ONE place the leave statement can place the program...
That is after the EndRepeat statement... The programmer can only
make a mistake in his logic (does he really want to LEAVE this
loop at this time?)... He can make NO mistake in his syntax... 
 
If this statement is replaced with a GOTO, he needs to add a label.
Once the issue of labels enters into the picture, any NUMBER of
errors can start to crop up... He can misplace the label... He can
misspell the label... (and end up somewhere else entirely)...
Also, maintenance becomes a problem... If someone comes along and
modifies the program by putting a new statement BETWEEN the end
of the loop and our label, we may be kaboshed...

Don't tell me that any of you have never had this kind of problem
in a program with GOTOs:  
 
   Repeat...
    ...
    if ... then goto xx2;
    ...
   EndRepeat;
   xx1: ... (place we WANTED to goto)
    ...
    (much later in program)
   xx2: ... (we did NOT want to end up here)
 
If you can honestly say this has never happened to you (and you use
gotos) then you are the most accurate programmer I have ever met...
This kind of error, especially in a large program with lots of labels
and sympathetic behavior (i.e., where what happens in the wrong place
is close enough to what you wanted to happen that simple testing may
not even disclose the problem... things don't go BANG until the absolute
worst moment) can be extremely difficult to uncover...

This does not mean that by removing Gotos we can eliminate problems...
However, in my years of working with and teaching younger programmers,
I have found that by enforcing rigorous structured programming on them,
I reduce their level of errors considerably... Those that embrace the
idea become much better programmers... those that object do not generally
become as good...
 
Is this a religion?  Absolutely not... There are obvious times when the
use of a judicious GOTO is appropriate (certain kinds of error handling
come to mind)... All I am trying to say is that the use of a GOTO exposes
you to more error potential than programs without GOTOs and you have to
be appropriately careful in that situation... Use many comments, explain
WHY you are using the goto, make the label clear and unambiguous, double
check everthing, and hope for the best...