RR0/rr0.org

<!--#include virtual="/header-start.html" -->
<title>Contre l'instruction GO TO</title>
<meta content="https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html" name="url"/>
<meta content="Dijkstra, Edsger W. (Technological University Eindhoven, The Netherlands)" name="author"/>
<!--#include virtual="/header-end.html" -->
<span class="source">"Go To Statement Considered Harmful", Comm. ACM 11 (March 1968), march 1968, pp. 147–148"</span>
<p>
  Depuis un certain nombre d'années j'observe régulièrement que la qualité des programmeurs diminue en fonction de la
  densité d'instructions go to dans les programmes qu'ils produisent. Par la suite j'ai découvert pourquoi l'utilisation
  de l'instruction go to a des effets si désastreux et suis devenu convaincu que l'instruction go to devrait être abolie
  de tous les langages de programmation "haut niveau" (i.e. tous sauf — peut-être — le code machine lui-même). A cette
  époque je n'attachais pas trop d'importance à cette découverte ; je soumets maintenant mes considérations pour
  publication, ayant été incité à le faire dans des dicussions très récentes où le sujet a été soulevé. </p>
<p>Ma 1<sup>ère</sup> remarque est que, bien que l'activité du programmeur se termine quand il a construit un programme
  correct, le processus taking place under control of his program is the true subject matter of his activity, for it is
  this process that has to effectuate the desired effect, it is this process that in its dynamic behaviour has to
  satisfy the desired specifications. Yet, once the program has been made, the “making” of the corresponding process is
  delegated to the machine. </p>
<p>Ma 2<sup>nde</sup> remarque est que nos capacités intellectuelles sont plutôt geared to master static relations and
  that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do
  (as wise programmers aware of our limitations) our utmost best to shorten the conceptual gap between the static
  program and the dynamic process, to make the correspondence between the program (spread out in text space) and the
  process (spread out in time) as trivial as possible. </p>
<p>Let us now consider how we can characterize the progress of a process. (You may think about this question in a very
  concrete manner: suppose that a process, considered as a time succession of actions, is stopped after an arbitrary
  action, what data do we have to fix in order that we can redo the process until that very same point?) If the program
  text is a pure concatenation of, say, assignment statements (for the purpose of this discussion regarded as the
  descriptions of single actions) it is sufficient to point in the program text to a point between two successive action
  descriptions. (In the absence of go to statements I can permit myself the syntactic ambiguity in the last three words
  of 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 a suitable
  place in the text a "textual index". </p>
<p>When we include conditional clauses (if B then A), alternative clauses (if B then A1 else A2), choice clauses as
  introduced by C.A.R.Hoare (case[i] of (A1, A2,.....,An)) or conditional expressions as introduced by J. McCarthy (B1 →
  E1, B2 → E2,....., Bn → En), the fact remains that the progress of the process remains characterized by a single
  textual index.</p>
<p> As soon as we include in our language procedures we must admit that a single textual index is no longer sufficient:
  in the case that a textual index points to the interior of a procedure body the dynamic progress is only characterized
  when we also give to which call of the procedure we refer. With the inclusion of procedures we can characterize the
  progress of the process via a sequence of textual indices, the length of this sequence being equal to the dynamic
  depth of procedure calling.</p>
<p> Let us now consider repetition clauses (like, while B repeat A or repeat A until B). Logically speaking, such
  clauses are now superfluous, because we can express repetition with the aid of recursive procedures. For reasons of
  realism I don't wish to exclude them: on the one hand repetition clauses can be implemented quite comfortably with
  present day finite equipment, on the other hand the reasoning pattern known as “induction” makes us well equipped to
  retain our intellectual grasp on the processes generated by repetition clauses. With the inclusion of the repetition
  clauses textual indices are no longer sufficient to describe the dynamic progress of the process. With each entry into
  a repetition clauses, however, we can associate a so-called “dynamic index”, inexorably counting the ordinal number of
  the corresponding current repetition. As repetition clauses (just as procedure calls) may be applied nestedly, we find
  that now the progress of the process can always be uniquely characterized by a (mixed) sequence of textual and/or
  dynamic indices. </p>
<p>The main point is that the values of these indices are outside programmer's control: they are generated (either by
  the write up of his program or by the dynamic evolution of the process) whether he wishes or not. They provide
  independent coordinates in which to describe the progress of the process. </p>
<p>Why do we need such independent coordinates? The reason is—and this seems to be inherent to sequential processes—that
  we can interpret the value of a variable only with respect to the progress of the process. If we wish to count the
  number, n say, of people in an initially empty room, we can achieve this by increasing n by 1 whenever we see someone
  entering the room; in the in-between moment that we have observed someone entering the room but have not yet performed
  the subsequent increase of n, its value equals the number of people in the room minus one! </p>
<p>The unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a
  meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the
  values of some well chosen variables, but this is out of the question because it is relative to the progress that the
  meaning of these values is to be understood! With the go to statement one can, of course, still describe the progress
  uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock).
  The difficulty is that such a coordinate, although unique, is utterly unhelpful: in such a coordinate system it
  becomes an extremely complicated affair to define all those points of progress where, say, n equals the number of
  persons in the room minus one!</p>
<p> The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one's
  program. One can regard and appreciate the clauses considered as bridling its use. I do not claim that the clauses
  mentioned are exhaustive in the sense that they will satisfy all needs; but whatever clauses are suggested (e.g.
  abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be
  maintained to describe the process in a helpful and manageable way.</p>
<p> It is hard to end this article with a fair acknowledgement: am I to judge by whom my thinking has been influenced?
  It is fairly obvious that I am not uninfluenced by Peter Landin and Christopher Strachey, and that I do not regret
  their influence upon me. Finally I should like to record (as I remember it quite distinctly) how Heinz Zemanek at the
  pre-ALGOL meeting in early 1959 in Copenhagen quite explicitly expressed his doubts whether the go to statement should
  be treated on equal syntactic footing with the assignment statement. To a modest extent I blame myself for not having
  then drawn the consequences of his remark. </p>
<p>The remark about the undesirability of the go to statement is far from new. I remember having read the explicit
  recommendation to restrict the use of the go 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, Sec. 3.2.1] Wirth and Hoare together make a remark in the same
  direction in motivating the case construction: “Like the conditional, it mirrors the dynamic structure of a program
  more clearly than go to statements and switches, and it eliminates the need for introducing a large number of labels
  in the program.”</p>
<p> In [2] Guiseppe [sic] Jacopini seems to have proved the (logical) superfluousness of the go to statement. The
  exercise to translate an arbitrary flow diagram more or less mechanically into a jumpless one, however, is not to be
  recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one. </p>
<p>REFERENCES: Wirth, Niklaus, and Hoare, C.A.R. A contribution to the development of ALGOL. Comm. ACM 9 (June 1966),
  413–432. Böhm, Corrado, and Jacopini, Guiseppe. Flow diagrams, Turing machines and languages with only two formation
  rules. Comm. ACM 9 (May 1966), 366–371.</p>
<!--#include virtual="/footer.html" -->