Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!elroy.jpl.nasa.gov!decwrl!mejac!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: <21350@oolong.la.locus.com>
Date: 18 Jan 91 21:19:36 GMT
References: <7612@plains.NoDak.edu> <2802@oucsace.cs.OHIOU.EDU> <1991Jan18.151104.13742@maverick.ksu.ksu.edu>
Distribution: usa
Organization: Locus Computing Corp, Los Angeles
Lines: 77

In article <1991Jan18.151104.13742@maverick.ksu.ksu.edu> mac@harris.cis.ksu.edu (Myron A. Calhoun) writes:
>In article <2802@oucsace.cs.OHIOU.EDU> tswingle@oucsace.cs.OHIOU.EDU (Tom Swingle) writes:
>
>   [many lines deleted]
>
>>....(by the way isn't exit just a special form of goto?) 
>
>Yes.  Also BREAK.  In assembly language the "GOTO-less" style was
>achieved by simple renaming:  JuMP, BRAnch, etc.!-)
>
>And CASE, THEN/ELSE/ELSEIF, and similar constructs have GOTO's
>"hidden" within them.
>
>Sometimes such "hiding" makes things easier to understand, and
>sometimes working around such hiding makes things harder to understand.
>
>Or, putting it another way,
>sometimes unhidden GOTO's make things harder to understand, and
>sometimes including them deliberately makes things easier to understand.
>
>GOTO's are a tool much as a sharp knife is a tool.  They may both be
>used wisely or foolishly or not at all.

This philosophy, IMHO, is incorrect... of course, CASE, IF/THEN/ELSE,
WHILE, etc have hidden branch instructions... These are not, however,
GOTOs in the sense intended by Dikstra in his famous article... 
What is objected to when one talks about "GOTO-less programming" is
the use of unrestricted or undisciplined branching... The actual words
used to describe the branch mechanism are not relevant... A GoTo/Jump
Branch are the same thing... A one-way leap into the hell of unstructured
programming... CASE, IF/THEN/ELSE, WHILE, REPEAT, etc are highly disciplined
structured constructs that, while containing branches, enforce a rigor that
makes it less likely to have errors in the code... They have a beginning
and an end... Gotos (and their derivatives) have only a beginning (or and
end depending on your view...)... Does this make LEAVE/EXIT/RETURN Gotos?
Of course not... they are disciplined exit mechanisms for structrured
constructs... You don't get to say where you want to GOTO... You only 
can say I want to leave from here (this is not always true of some
languages aberational Leaves where you can add a label)... Maybe this
should better be called label-less programming... Any construct that
works in a label-less environment is a good one... If you need a label
to get there (i.e., with a traditional GOTO) it is probably bad...
 
Example:
 
   WHILE1 something
    ...
     WHILE2 something
      ...
     ENDWHILE2
    ...
   ENDWHILE1

is a legal structured programming construct...     
whereas:

    WHILE1 something
     ...
      WHILE2 something
    ENDWHILE2
       ...
      ENDWHILE2
is obviously illegal...
This is preventable in GOTOless programming by the compiler...
It is not preventable in programming where the normal 
labelled GOTO is permitted...

I have NEVER seen a situation where use of a real labelled GOTO
made something clearer... Depending on the compiler it may have
made it faster... that is always possible... But that is not
a good justification for supporting the use of a bad construct...
It is a justification for better compilers that can optimize
the performance of the program without requiring that the 
programmer destroy the clean semantics of the code...
 
Jon Rosen