STRUCTURE EXITS, NOT LOOPS

Transcription

1 STRUCTURE EXITS, NOT LOOPS Mordechai Ben-Ari Department of Science Teaching Weizmann Institute of Science Rehovot Israel Copyright c 1996 by the Association for Computing Machinery, Inc. ABSTRACT Until recently, Pascal was the first programming language taught to students. As more schools choose Ada or C++ as a first language, the debate on structured programming has been reopened ([Rob95]). We are no longer restricted to the while-statement: exit/break-statements can be used to exit a loop from the middle, and return from a procedure or function is allowed within a loop statement. Do these constructs violate the principle of structure programming? This article claims that more general loop constructs can be objectively justified, because they simplify the verification of programs. A program that is simple to verify is also easy to explain and understand. INTRODUCTION In his paper at the 1995 SIGCSE Symposium [Rob95], Eric Roberts re-examines the subject of language constructs for loops. He claims that loops need not be restricted to constructs that exit at the ning (or end) of the loop; a program can be well-structured even if: a break-statement is used to exit from the middle of the loop, or a return-statement is used both to exit the loop and to return from a function. Roberts analysis is based on stylistic grounds, namely that forcing loops into while-statements or repeat-statements, as required by Pascal, can make the program unnatural or unnecessarily complex. This paper supports Roberts conclusions, but for different reasons. We claim that the objective criterion that should be used to compare programs is the simplicity of the assertions required for verification. This claim is independent of the decision of a lecturer or a textbook author to discuss verification. Programs that have simple formal proofs will have simple informal proofs. WHERE TO EXIT A LOOP Where should we place the exit point of a loop? Actually, it doesn t matter. Any loop will have an invariant and an exit condition. There is no a-priori reason to suppose that an exit at the start of the loop is better than an exit from the middle. Furthermore, there is no a-priori reason to suppose that understanding (i.e. reasoning about) two simple exit conditions is more complex than understanding a single exit with a compound condition. Teachers of Pascal in local high schools claim that the while-statement is very difficult to teach, and we conjecture that the identification of the loop entry with the loop exit is one source of the difficultly. Another is that while-loops are unnatural in ordinary speech. Compare the following two sentences: While you haven t reached Central Ave., drive straight. Drive straight; exit when you reach Central Ave. Thus it would probably be better to teach a neutral construct such as the Ada loop-statement with an arbitrary exit:

2 loop... exit when... ;... Then the loop concept can be taught independently of the exit concept. In the following sections, we survey some elementary algorithms and show how arbitrary, but elementary, exits lead to programs that are easier to reason about than classical while-loops. The program fragments are written in Ada, but they can easily be translated into other languages like C++. VERIFICATION OF LOOPS My introduction to program verification was from Zohar Manna s textbook [Man74]. Manna introduces verification techniques first on flowchart programs, and only then in the form of Hoare triples {Pre}Program{Post} on structured programs. It is probably not coincidental that many of the flowchart programs in the text and exercises presumably chosen to be relatively easy to verify contain exits from within the loops, rather than from their ning or end. Consider problem 3.6 from (page 227) which is a naive program for deciding if a number is prime. We translated the flowchart program to use an exit-statement: 1 {X 2} while Y X loop exit when X mod Y = 0; Prime := Y = X; {Prime i(1 < i < X (X mod i 0)} The loop invariant is simply: i(1 < i < Y (X mod i 0) and the informal explanation of the algorithm is: Each time around the loop, check that the next number does not divide X. 1 Read the postcondition as: the value of the (Boolean) variable Prime is true, if and only if, for all i such that i is between 1 and X, X mod i 0. To prove the invariant we simply note that for an execution of the body of the loop, if the exit is skipped, X mod Y 0, and Y is increased by 1. To prove the postcondition, we have to check two cases: You exit the loop because Y = X, which implies that i(1 < i < X (X mod i 0) is true. You exit the loop from X mod Y = 0 for Y < X, in which case i(1 < i < X (X mod i 0) is false. The use of a while-statement requires a compound condition: while (X Y) and (X mod Y /= 0) loop The compound condition combines two separate conditions: X mod Y 0, which is essential in proving the invariant, and X < Y which is relevant only upon termination. A standard way of simplifying compound conditions is to use a flag or state variable: {X 2} Prime := True; while Prime and (Y X) loop if X mod Y = 0 then Prime := False; else {Prime i(1 < i < Y (X mod i 0)} This I regard as unacceptable since the invariant is no longer a simple predicate, but an equivalence: Prime ( i(1 < i < Y (X mod i 0)) To prove the equivalence you must prove four, rather than two, verification conditions. The variable Prime can be either true or false, and the condition (X mod i 0) can be either true or false. Corresponding to each formal verification condition is an informal argument that must be explained. Actually, the whole discussion is moot because you don t even need the extra exit. Since X necessarily divides itself, there is no reason to check an additional exit condition: 2

3 {X 2} while X mod Y /= 0 loop Prime := Y = X; {Prime i(1 < i < Y (X mod i 0)} SENTINELS The prime number algorithm demonstrates that the best way to solve the dilemma between additional loop exits and compound Boolean conditions is simply to avoid it by using sentinels. The classic linear search problem becomes trivial even with limited control structures: type IntList is array(0..max) of Integer; I: Integer := Max; List(0) := Key; while L(I) /= Key loop I := I - 1; return I; The loop invariant is simply: J (I < J Max List(J ) Key) The advantages of a using sentinel are: The algorithm is simple because there is only one exit with an elementary condition. Verification is simple because the partial correctness expressed by the loop invariant is separated from the termination condition. The algorithm is more efficient. Sentinels are a very general programming paradigm and should be learned as early as possible. In particular, when students are later introduced to list processing, sentinels can be used to avoid compound conditions that check for null pointers. Roberts use of the linear search problem to justify break ing a loop in the middle is somewhat surprising. Over twenty years ago in his goto-paper [Knu74], Knuth justifies the use of goto in a linear search using arguments similar to Roberts, but immediately adds (p. 267): Unfortunately, however, the example is totally unconvincing in spite of the arguments I ve stated so far, because the method in Example 1 is almost never a good way to search an array for x! According to Knuth, the better way to search an array is, of course, to use a sentinel. With sentinels one is not subject to the numerous bugs that can occur when trying to program linear search, especially if indices are limited to subranges. Thus it is all the more interesting that popular introductory programming texts like [Coo93] and [Kof92] do not even mention sentinels (except as indicators of the end of a sequence of input data). In a high-school course under development at this department, sentinel search is taught as the primary technique, while flags are only later introduced to demonstrate programming with Boolean variables. I observed a class of ordinary, not excellent, students learning the material. They easily understood the sentinel search, but found the compound condition with a flag to be quite difficult. A NOTE ON return There is nothing wrong with using more than one return-statement, or with using the statement within a loop. A subprogram exists solely to establish its postcondition. Once the postcondition is established, there is no reason to remain within the subprogram. Using linear search again: 2 for I in List Range loop if L(I) = Key then return I; 2 In this section, the index of the array type is 1..Max. 3

4 return 0; The postcondition is: (List(I) = Key) ((I = 0) J (1 J Max (List(J ) Key)) and it is trivial to see that the first part is established by return I, while the other part follows immediately from the invariant. A situation is more dramatic in the binary search algorithm. Sedgewick (p. 198) uses a repeat-statement with a compound condition, followed by an ifstatement to distinguish among the cases! But once we have established the required postcondition, there is no reason to tarry within the function: Low: Integer := List First; High: Integer := List Last; Mid: Integer; loop Mid := (Low + High) / 2; if Key = A(Mid) then return Mid; elsif Key A(Mid) then High := Mid - 1; else Low := Mid + 1; if Low High then return 0; Each return-statement establishes part of the postcondition. AN ADVANCED EXAMPLE Even in advanced courses, it pays to search for elementary exit conditions, rather than to insist on structured loops. One example is the representation of a heap by an array, which can be used to develop heapsort a sort algorithm which is O(n log n) even in the worst case. In the representation, array elements 2i and 2i + 1 hold the children of element i. Heap algorithms create and maintain the heap property: every node is larger than its two children. We will not go into the algorithm in detail (see [Man74], [Wir76], [Sed88], [CLR90]). The first three texts give iterative versions of the algorithm which use a second exit from the middle of the loop of the Siftup procedure. The procedure is very difficult to understand and its correctness proof [Lon70] is complex. The source of the complexity (of both the algorithm and its proof) is an optimization designed to cascade exchanges of elements. If we remove the optimization, a loop with one exit (in the middle!) is obtained, as shown by the following program which is an iterative version of the recursive program in [CLR90]: loop L := 2*I; R := 2*I+1; if L = Max and A(L) A(I) then Large := L; else Large := I; if R = Max and A(R) A(Large) then Large := R; exit when Large = I; Swap(A(I), A(Large)); I := Large; The program computes which of the two children holds the largest value, stores its index into Large, and exits if neither child is larger than its parent. The loop invariant is: A is a permutation of the original array and the heap property holds everywhere except possibly at i. The complex computation of the exit condition gives the algorithm the form of a loop-and-a-half. Despite the exit from within the loop, this form of program and its proof are relatively easy to understand. CONCLUSION The point of structured programming is to create programs that are easy to understand and easy to verify. The term should not be associated with a particular language construct such as the while-statement. We have shown that the simplicity of loop exit conditions is an excellent criterion that can be used to decide if a program is structured. This is also a justification for including formal verification in the undergraduate 4

5 computer science curriculum: it furnishes the student with an objective tool for judging the quality of programs. REFERENCES [CLR90] Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest. Introduction to Algorithms. MIT Press, Cambridge, MA, [Coo93] Doug Cooper. Oh! Pascal! (Third Edition). W.W. Norton, New York, [Knu74] Donald E. Knuth. Structured programming with go to statements. Computing Surveys, 6(4): , December [Kof92] Eliot B. Koffman. Pascal: Problem Solving and Program Design (Fourth Edition). Addison- Wesley, Reading, MA, [Lon70] Ralph L. London. Certification of algorithm 245: Treesort 3. Communications of the ACM, 13(6): , June [Man74] Zohar Manna. Mathematical Theory of Computation. McGraw-Hill, New York, [Rob95] Eric S. Roberts. Loop exits and structured programming: Reopening the debate. In Twenty- Sixth SIGCSE Technical Symposium, pages , [Sed88] Robert Sedgewick. Algorithms (Second Edition). Addison-Wesley, Reading, MA, [Wir76] Niklaus Wirth. Algorithms + Data Structures = Programs. Prentice-Hall, Englewood Cliffs, NJ,