For a number of years I have been familiar with the observation that the qualityof programmers is a decreasing function of the density ofgo to statementsin the programs they produce. More recently I discovered why the use of thegoto statement has such disastrous effects, and I became convinced that thegoto statement should be abolished from all “higher level” programming languages(i.e. everything except, perhaps, plain machine code). At that time I did notattach too much importance to this discovery; I now submit my considerations forpublication because in very recent discussions in which the subject turned up, Ihave been urged to do so

My first remark is that, although the programmer’s activity ends when he hasconstructed a correct program, the process taking place under control of hisprogram is the true subject matter of his activity, for it is this process thathas to accomplish the desired effect; it is this process that in its dynamicbehavior has to satisfy the desired specifications. Yet, once the program hasbeen made, the “making’ of the corresponding process is delegated to themachine.

My second remark is that our intellectual powers are rather geared to masterstatic relations and that our powers to visualize processes evolving in time arerelatively poorly developed. For that reason we should do (as wise programmersaware of our limitations) our utmost to shorten the conceptual gap between thestatic program and the dynamic process, to make the correspondence between theprogram (spread out in text space) and the process (spread out in time) astrivial as possible.

Let us now consider how we can characterize the progress of a process. (You maythink about this question in a very concrete manner: suppose that a process,considered as a time succession of actions, is stopped after an arbitraryaction, what data do we have to fix in order that we can redo the process untilthe very same point?) If the program text is a pure concatenation of, say,assignment statements (for the purpose of this discussion regarded as thedescriptions of single actions) it is sufficient to point in the program text toa point between two successive action descriptions. (In the absence ofgo tostatements I can permit myself the syntactic ambiguity in the last three wordsof the previous sentence: if we parse them as “successive (action descriptions)”we mean successive in text space; if we parse as “(successive action)descriptions” we mean successive in time.) Let us call such a pointer to asuitable place in the text a “textual index.”

When we include conditional clauses (ifBthenA), alternativeclauses (ifBthenA1elseA2), choice clauses as introducedby C. A. R. Hoare (case[i] of (A1,A2, ···,An)), or conditionalexpressions as introduced by J. McCarthy (B1 →E1,B2 →E2, ···,Bn →En), the fact remains that the progress of the process remains characterizedby a single textual index.

As soon as we include in our language procedures we must admit that a singletextual index is no longer sufficient. In the case that a textual index pointsto the interior of a procedure body the dynamic progress is only characterizedwhen we also give to which call of the procedure we refer. With the inclusion ofprocedures we can characterize the progress of the process via a sequence oftextual indices, the length of this sequence being equal to the dynamic depth ofprocedure calling.

Let us now consider repetition clauses (like,whileBrepeatA orrepeatAuntilB). Logically speaking, such clauses are nowsuperfluous, because we can express repetition with the aid of recursiveprocedures. For reasons of realism I don’t wish to exclude them: on the onehand, repetition clauses can be implemented quite comfortably with present dayfinite equipment; on the other hand, the reasoning pattern known as “induction”makes us well equipped to retain our intellectual grasp on the processesgenerated by repetition clauses. With the inclusion of the repetition clausestextual indices are no longer sufficient to describe the dynamic progress of theprocess. With each entry into a repetition clause, however, we can associate aso-called “dynamic index,” inexorably counting the ordinal number of thecorresponding current repetition. As repetition clauses (just as procedurecalls) may be applied nestedly, we find that now the progress of the process canalways be uniquely characterized by a (mixed) sequence of textual and/or dynamicindices.

The main point is that the values of these indices are outside programmer’scontrol; they are generated (either by the write-up of his program or by thedynamic evolution of the process) whether he wishes or not. They provideindependent coordinates in which to describe the progress of the process.

Why do we need such independent coordinates? The reason is—and this seems to beinherent to sequential processes—that we can interpret the value of a variableonly with respect to the progress of the process. If we wish to count thenumber, say, of people in an initially empty room, we can achieve this byincreasing by one whenever we see someone entering the room. In the in-betweenmoment that we have observed someone entering the room but have not yetperformed the subsequent increase of, its value equals the number of people inthe room minus one!

The unbridled use of thego to statement has an immediate consequence thatit becomes terribly hard to find a meaningful set of coordinates in which todescribe the process progress. Usually, people take into account as well thevalues of some well chosen variables, but this is out of the question because itis relative to the progress that the meaning of these values is to beunderstood! With thego to statement one can, of course, still describe theprogress uniquely by a counter counting the number of actions performed sinceprogram start (viz. a kind of normalized clock). The difficulty is that such acoordinate, although unique, is utterly unhelpful. In such a coordinate systemit becomes an extremely complicated affair to define all those points ofprogress where, say,n equals the number of persons in the room minus one!

Thego to statement as it stands is just too primitive; it is too much aninvitation to make a mess of one’s program. One can regard and appreciate theclauses considered as bridling its use. I do not claim that the clausesmentioned are exhaustive in the sense that they will satisfy all needs, butwhatever clauses are suggested (e.g. abortion clauses) they should satisfy therequirement that a programmer independent coordinate system can be maintained todescribe the process in a helpful and manageable way.

It is hard to end this with a fair acknowledgment. Am I to judge by whom mythinking has been influenced? It is fairly obvious that I am not uninfluenced byPeter Landin and Christopher Strachey. Finally I should like to record (as Iremember it quite distinctly) how Heinz Zemanek at the pre-ALGOL meeting inearly 1959 in Copenhagen quite explicitly expressed his doubts whether thegoto statement should be treated on equal syntactic footing with the assignmentstatement. To a modest extent I blame myself for not having then drawn theconsequences of his remark

The remark about the undesirability of thego to statement is far from new.I remember having read the explicit recommendation to restrict the use of thego to statement to alarm exits, but I have not been able to trace it;presumably, it has been made by C. A. R. Hoare. In^[1] Wirth and Hoare togethermake a remark in the same direction in motivating the case construction: “Likethe conditional, it mirrors the dynamic structure of a program more clearly thango to statements and switches, and it eliminates the need for introducing alarge number of labels in the program.

In^[2] Guiseppe Jacopini seems to have proved the (logical) superfluousness ofthego to statement. The exercise to translate an arbitrary flow diagrammore or less mechanically into a jump-less one, however, is not to berecommended. Then the resulting flow diagram cannot be expected to be moretransparent than the original one