This paper contains a suggestion for a calculus for constructing 'flowchartable' algorithms. The calculus is a generalization of an Algol-like calculus, and hence maintains some discipline over the algorithms constructible with it.The essence of the great 'go to' debate seems to be that the use of the 'go to' device allows the construction of 'spaghetti-like' algorithms which are difficult to control intellectually, and hence that only more restrictive, special-purpose control structures (which are presumably well thought out) should be used. Another way of saying this, perhaps, is that the 'go to' device is the most primitive (and hence most general) possible control structure, and though implementations of any control structure will ultimately have to be done using it, a programmer should no more be content using a 'go to' than if he were forced to use bit strings for data types. He should be demanding higher-level control structures. To some extent, of course, he has them; but, in discussing the 'go to' debate, the conclusion arrived at by Knuth (1), for instance, is that more powerful control structures than are freely available at present are needed to enable programmers to express their algorithms. He mentions a suggestion by Zahn (2) for strengthening the set of available control structures, but shows that he still needs to resort to the dreaded 'go to' device. (He confesses a sinful urge to jump into the middle of Zahn's loops.) The implication is that even with Zahn's suggestions there is a need for more control structures. We concur with this view, and present here a suggestion for making more such structures available. We invite discussion as to whether the results are profitable for programming language design.The lack of well-developed control structures is manifested, incidentally, not only in the dearth of 'public' control structures (i.e. made freely available to all users), but also in the lack of facilities for creating 'private' ones (analogously to the notion of 'subroutines' or user-defined data types). These deficiencies are not all that surprising since control structures are, in a sense, devices at a third level of sophistication: data (being the first level) is acted upon by programs (being the second level) to produce other data; and programs are acted upon by control structures to produce other programs. But the time has perhaps come to pay some more attention to control structures.

This paper discusses the computation of finite functions with the aim of investigating ways of judging the relative worth of the different methods for computing a given finite function. Any finite function may, of course, be computed in a number of ways, including a “brute-force” method of table look-up and methods which exploit some pattern which may exist in the function. How “good” we judge each of the several methods to be will depend on which criteria we wish to apply, and here we will be considering two: size of program and cost of computation, first of all separately, and then together. The latter case gives rise to the notion of a “reasonable” way of computing a finite function, and certain considerations with respect to this notion suggest a modified notion of “relatively reasonable”. Some properties of these concepts, in particular some of the differences between them, are developed. The spirit of the paper is machine-independent except for the last paragraph which suggests a need for some idea of “program structure” to be introduced into the formulation.