NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/arch/10553

Text File | 1992-11-09 | 3.5 KB | 66 lines

Newsgroups: comp.arch
Path: sparky!uunet!ukma!darwin.sura.net!convex!news.oc.com!utacfd.uta.edu!seas.smu.edu!shyamal
From: [e-mail] (Shyamal Prasad)
Subject: What's wrong with goto's
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: turbo_f.seas.smu.edu
Organization: SMU School Of Engineering and Applied Science
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 9 Nov 1992 17:32:29 GMT
Lines: 53

    The 'goto' thread on the newsgroup is really something else. However
it seems that the basic question is "What is wrong with the goto?",
and no one seems to answer this one. This discussion may even be in
the wrong group - but since there is so much interest, here goes.....

    Disclaimer: I am not here with all the answers,
and nothing I have to say is very original, and I am not an
authority on this. I am just trying to state a viewpoint that I
feel has not been put strongly enough in this discussion.

    In the first place there is nothing wrong with the goto
statement itself, it's the *label* that creates the problem ! (And
this is a relatively well known, but often forgotten, viewpoint)

    "Understanding" a program is, in my opinion, about
intuitively getting the hang of invariants. But when we see a goto
our intuitive understanding of an invariant condition gets thrown off
because we are really not sure where we "came from". We don't know
(formally or intuitively) what the invariants are any more when we see
a label. If we use labels and ensure that we jump to them
carefully enough that some (useful) invariant is always satisfied
then we are doing okay, are we not? After all if we are sure that a
certain condition holds at a label we have *not* lost any clarity over
an equivalent structured program without the goto.

    The reaction to the goto is a cultural thing. It just looks ugly,
but we never *really* question why. Try implementing a finite machine
with each state implemented with  code marked by a label. Transitions
between states are goto statements. I always do this - it works because
each label marks an entry to a state of the machine, and the machine
states are so well defined! I don't lose any clarity because my labels
always have well defined invariant conditions on entry. This seems to be
so much clearer than the so called 'structured versions' that I tried.

    Structured programming has little to do with the lack of using
goto statements - it has to do with improving code clarity. I never read
Herman Rubin's code, only because it was *so* unclear, if you use
goto statements make sure they improve clarity. That is the final
arbiter; I have always believed that efficient programs can be
clear (with or without gotos). I am not sure if Rubin's code runs better
with all those goto's or not, but the real point is that if he uses goto
statements he should do it with discipline.

    I even ask myself : What is the use of break statements that
are more powerful than the simple single level one like we have in C?
CLU and ADA need some way to specify the level to which execution
should exit. What is the point of replacing the goto ?? If we used
a goto with a label *have we lost any clarity*? After all the label
is there only to provide an early break or continue....use it in
just that way ("keep you invariants true").
--
Shyamal Prasad, Department of Computer Science
Southern Methodist University, Dallas TX 72275