The Science of Programming David Gries 5 Springer-Verlag New York Heidelberg BerlinChapter 14 Programming as a Goal-Oriented Activity A simple example of program development Consider the following problem. Write a program that, given fixed integers x and y, sets z to the maximum of x and y. (Throughout, we use the convention that variables called “fixed” should not be changed by execution of the program. See section 6.3.) Thus, a command S is desired that satisfies (14.1) {7} S {R:z =max(x, y)}. Before the program can be developed, R must be refined by replacing max by its definition —after all, without knowing what max means one cannot write the program. Variable z contains the maximum of x and y if it satisfies (14.2) RizBxAzBy A(z=xVz=y) Now, what command could possibly be executed in order to establish (14.2)? Since (14.2) contains z =x, the assignment z:= x is a possibility. The assignment z:= x +! is also a possibility, but z:= x is favored for at least two reasons. First, it is determined from R: to achieve z =x assign x toz. Second, it is simpler. To determine the conditions under which execution of z:= x will actu- ally establish (14.2), simply calculate wp(“z:= x”, R): wp(“z:= x", R)=xBxAxBy A(x=xVx=y) =TAx>yA(TVx=y) =xBy This gives us the conditions under which execution of z:= x will establish R, and our first attempt at a program can beChapter 14 Programming as a Goal-Oriented Activity 173 ifx>y -z:=x fi This program performs the desired task provided it doesn’t abort. Recall from Theorem 16.5 for the Alternative Construct that, to prevent abor- tion, precondition Q of the construct must imply the disjunction of the guards, i.e. at least one guard must be true in any initial states defined by Q. But Q, which is T, does not imply x >y. Hence, at least one more guarded command is needed. Another possible way to establish R is to execute z= y. From the above discussion it should be obvious that y >x is the desired guard. Adding this guarded command yields (14.3) ifx2y ~ z= x Dy Sx zy fi Now, at least one guard is always true, so that this is the desired program. Formally, we know that (14.3) is the desired program by theorem 16.5. To apply the theorem, take Sy: z=x Sp z=y Bix>y By y>x P: T RizBxAzbya(z=xVz=y) Discussion The above development illustrates the following (14.4) Principle: Programming is a goal-oriented activity. By this we mean that the desired result, or goal, R, plays a more impor- tant role in the development of a program than the precondition Q. Of course, Q also plays a role, as will be seen later. But, in general, more insight is gained from the postcondition. The goal-oriented nature of pro- gramming is one reason why the programming notation has been defined in terms of weakest preconditions (rather than strongest postconditions —see exercise 4 of section 9.1). To substantiate this hypothesis of the goal-oriented nature of program- ming, consider the following. Above, the precondition was momentarily put aside and a program was developed that satisfied {2} S {R: z =max(x, y)}; whenever S was considered complete, the requirement Q >wp(S,R) was checked. Try doing opposite: forget about postcondition R, and try to174 Part III. The Development of Programs develop a program S satisfying only {T}S {7} Whenever S is thought to be complete, check whether T > wp(S, z=max(x,y)), or T > wp(S,(14.2)). How many programs S will you write before a correct one is found? Another principle used in the above development is: (14.5) ©Principle: Before attempting to solve a problem, make absolutely sure you know what the problem is. In programming, this general principle becomes: (14.6) @Principle: Before developing a program, make precise and refine the pre- and postconditions. In the example just developed, the postcondition was refined while the precondition, which was simply T,, needed no refining. A problem is sometimes specified in a manner that lends itself to several interpretations. Hence, it is reasonable to spend some time mak- ing the specification as clear and unambiguous as possible. Moreover, the form of the specification can influence algorithmic development, so that striving for simplicity and elegance should be helpful. With some prob- lems, the major difficulty is making the specification simple and precise, and subsequent development of the program is fairly straightforward. Often, a specification may be in English or in some conventional nota- tion —like max(x, y)— that is at too “high a level” for program develop- ment, and it may contain abbreviations dealing with the applications area with which the programmer is unfamiliar. The specification is written to convey what the program is to do, and abstraction is often used to sim- plify it. More detail may be required to determine how to do it. The example of setting z to the maximum of x and y illustrates this nicely. It is impossible to write the program without knowing what max means, while writing a definition provides the insight needed for further develop- ment. The development of (14.3) illustrates one basic technique for develop- ing an alternative construct, which was motivated by theorem 10.5 for the Alternative Construct. (14.7) @Strategy for developing an alternative command: To invent a guarded command, find a command C whose execution will establish postcondition R in at least some cases; find a Boolean B satisfying B > wp(C,R); andChapter 14 Programming as a Goal-Oriented Activity 175 put them together to form B — C (see assumption 2 of the theorem). Continue to invent guarded commands until the precondition of the construct implies that at least one guard is true (see assumption | of the theorem). This technique, and a similar one for the iterative construct, is used often. Let us return to program (14.3) for a moment. It has a pleasing sym- metry, which is possible because of the nondeterminism. If there is no reason to choose between z:= x and z:= y when x =y, one should not be forced to choose. Programming requires deep thinking, and we should be spared any unnecessary irritation. Conventional, deterministic notations force the choice, and this is one reason for preferring the guarded com- mand notation. Nondeterminism is an important feature even if the final program turns out to be deterministic, for it allows us to devise a good programming methodology. One is free to develop many different guarded commands completely independently of each other. Any form of determinism, such as evaluating the guards in order of occurrence (e.g. the PL/I Select state- ment), drastically affects the way one thinks about developing alternative constructs. A second example Write a program that permutes (interchanges) the values of integer var- iables x and y so that x wp(S;, R), according to the Theorem for the Alter- native Construct. For the command skip, we have wp(skip,R)=R. Hence, B of the guarded command B — skip must satisfy Q 4 B>R. Since Q implies the second conjunct of R, the first conjunct x 0). That is, j and k should always satisfy j =k mod 10 Thus, j will only take on the values 0,1, --- ,9. Let us determine a com- mand to “increase k under the invariance of j =k mod 10”, assuming that function mod is not available.Chapter 14 Programming as a Goal-Oriented Activity 177 One possible command is k,j:= k +1, 7+1. However, this does the job only if before its execution j <9, and so we have the guarded com- mand j <9 — k, k+1, j+1. However, initially we have O0. Write a program to add 1 to k, keeping the property of x the same. That is, upon termination kK should be one more than it was initially and x should still contain the number of odd integers in b[0:k —1]. (d) Suppose integer variables @ and 6 satisly On, Is it possible to halve the interval a:b, by setting either a or b to (a +b)+2, at the same time keeping P true? Answer the question by trying to develop a pro- gram to do so. 2.(The Next Higher Permutation). Consider an integer of m decimal digits (n >0) contained in an array d[0:n—I], with d[0] being the high-order digit. For example, with n =6 the integer 123542 would be contained in d as d =(1,2,3,5,4,2). The next higher permutation of d[0:n—1] is an array a’ that represents the next higher integer composed of exactly the same digits. In the example given, the next higher permutation would be d’ =(1, 2,4, 2, 3, 5). The problem is to define precisely the next higher permutation d’ for an integer d[0:n—1]. Does your definition give any insight into developing a pro- gram to find it?