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 one 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! The unbridled use of the go to statement has 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! 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. It is hard to end this with a fair acknowledgment.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.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 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. In [2]Guiseppe 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 jump-less one,however,is not to be recommended.Then the resulting flow diagram cannot be expected to be more transparent than the original one. References: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 one 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! The unbridled use of the go to statement has 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! 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. It is hard to end this with a fair acknowledgment. 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. 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 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." In [2] Guiseppe 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 jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one. References: