🚀 go-pugleaf

In <4i0fj8$sd3@tierra.santafe.edu>, richrcar@internet.roadrunner.com (James Giles) writes:
>In 1968, Edsger Dijkstra wrote a letter to the _Communications_
>_of_the_ACM_ titled "Go To Statement Considered Harmful".  This
>paper has since been widely reprinted.  In 1974, Donald Knuth
>wrote a paper for _Computing_Surveys_ titled "Structured
>Programming with GOTO Statements".  This paper has also been
>widely reprinted.  These were not the first nor the only papers
>written on this subject, but to my mind, they should have been
>the last needed.  Anyone who argues this issue should first
>be required to prove he (or she) has read both these papers.
>Anyone who hasn't read these papers should be ignored out
>of hand.

Yep, I read those years ago (along with several titled "'Go To Statement
Considered Harmful' Considered Harmful", etc).  And I've got a copy of
the Dijkstra/Dahl/Hoare book around here somewhere.  What you said (in 
the portion of your post that I've omitted) is certainly true for the 
most part.  Whether or not you use GOTOs, and what sort of structuring 
statements you use otherwise or besides is not really that important.

But you failed to spell out what IS important.  The critical factor to 
consider here is how the structure of the program contributes to the 
control of complexity.  First off, it must be understood that "toy" 
examples are meaningless, since complexity isn't a factor at "toy" 
scales.  Thus, the issues involved in the "GOTO controversy" can only be
fully appreciated by those who have been involved in "real" large 
development complex projects -- projects where control of complexity was
a major consideration.

Once one is faced with this situation -- a project where complexity 
threatens to make the situation unmanageable -- the desireable features 
of a program structuring model become more apparent.  Foremost, one 
would like to have a model that supports a sort of "nested black box" 
approach.  Given a particular structuring construct (such as a DO-WHILE 
block), one would like to be able to define the function of the 
construct in a manner that's independent of its implementation. 
Dijkstra and Hoare pushed this concept with preconditions and invariants
and the like.  The "invariants" are the key here -- the idea that the
actions of a construct can be described as preserving most of the state
of the system unchanged (even if the state changes temporarily within 
the construct), while other parts of the state change in a well-defined 
fashion (those changes being the "function" of the construct).

It's this clear separation of preserved state vs changed state that's 
key:  With ordinary "non-structured" code it's easy for the two to get 
intermingled -- for temporarily changed state to get entwined with the 
changes that are to be a permanent result of the code segment under 
consideration.

Proper use of structure prevents this entwinement.  A "structured" code 
segment properly includes the statements at the front that make 
temporary changes to the system state along with statements at the end 
that undo those temporary changes.  And "proper" structure assures that 
there is no way to enter the segment -- making the temporary changes -- 
without subsequently leaving the segment through the code that undoes 
those temporary changes.

Proper structure also assures that the stated "function" of the segment 
ALWAYS occurs.  (For this reason, the function statement may include an 
error condition that is included as one of the possible outcomes.)

When these conditions are met, then it becomes possible to describe the 
function of the code segment as a true "black box", and this in turn 
allows one to ignore the internals of the segment when considering how 
to "plug" segments together.  Since the same concepts can be applied to 
larger and larger segments (composed of smaller segments), it becomes 
possible to build applications of arbitrary complexity without losing 
control.

Exactly what techniques are used to maintain the "invariants" depends on
personal preference, the skills of the programmers, etc.  If programmers
are sufficently skilled and also sufficiently self-controlled, plain old
assembly language will work pretty well (though it suffers the obvious 
productivity problems).  If programmers are not highly skilled, or if 
they can't be counted on to always exercise a high degree of 
self-restraint, then a GOTO-less "structured" language will help 
considerably (though not in itself assure a good outcome).

For my own part, I'd like to see more languages incorporate a 
prolog/function/epilog block as the primary structuring construct.  TRY 
blocks come close, but much more could be done.

Dan Hicks
http://www.millcomm.com/~danhicks/