Forum
call such a pointer to a suitable
place in the text a “textual index.”
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.
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.
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 clause,
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.
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.
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 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 explic-