The Text Pointer

Dijkstra in his anathema [1] on the GO TO statement explained that, for human intelligibility, progress through a program text must map easily to progress through the executed process. GO TO statements frustrate this desire. Abolish the GO TO statement, and we can substitute the clarity of structured programs for the obscurity of chaotic flowcharts. The benefit is undeniable: structured programming defines a coordinate system, elaborated to handle procedure calls and loops, for the program and process alike. Values of the text pointer (my term, not Dijkstra's) are points in this coordinate system.

But wait. Surely the program variable values already define the state of the computation, and hence a sufficient coordinate system, don't they? No, they don't. Dijkstra gives a tiny example. The meaning of a variable n, used in a program that counts how many people have entered a room, depends on whether or not the program execution has yet updated n to reflect the most recent entry. A better coordinate system for program text and program execution is a necessity. One way of thinking about this stipulation is to recognise that the text pointer itself is an undeclared program variable, implicit in the text semantics.

The famous GO TO letter combines two related—but quite distinct—themes. First, the human need to map a program's text easily to its execution: arbitrary GO TO statements make it impossible to satisfy this need. Second, the inadequacy of variable values for characterising execution progress. The letter might well have been entitled "GO TO Statement Considered Harmful and Variable Values Considered Inadequate."

Both of these themes are important in software engineering for cyber-physical systems. First, a triplet satisfying its simplicity criteria must execute a regular process—that is, its machine must be a structured program. Second, the governed behaviour in the physical world cannot be adequately described without reference to the program executed in the machine—specifically to its local variables, including—of course—the program's text pointer.

The second theme was compellingly evidenced in a project to specify an access control system in an event-based formalism. After much soul-searching, the specifiers decided that the formalism's lack of an explicit sequencing mechanism was intolerable; so they introduced an ad hoc feature for sequencing constraints on specified actions. Of course, the text pointer for a sequence was in truth the text pointer of the machine needed to govern the specified behaviour. A text pointer always denotes the progress state of a purposeful behaviour—either of the machine or of a purposeful participant in the governed world.

[1] E W Dijkstra; Go To Statement Considered Harmful; a letter to CACM, Volume 11, Number 3, March 1968.

Links to other posts:
 ↑ Triplets:  Triplets are system behaviour elements: (Machine+World=Behaviour)