The person charging this material is re- 
 sponsible for its return to the library from 
 which it was withdrawn on or before the 
 Latest Date stamped below. 
 
 Theft, mutilation, and underlining of books are reasons 
 for disciplinary action and moy result in dismissal from 
 the University. 
 To renew call Telephone Center, 333-8400 
 
 UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN 
 
 
 DEC 7 987 
 
 L161— O-1096 
 
. Or 
 
 Report No. UIUCDCS-R-81-1011 
 
 UILU-ENG 81 1717 
 
 June 1981 
 
 THE EVOLUTION OF PROGRAMS: PROGRAM 
 ABSTRACTION AND INSTANTIATION 
 
 by 
 
 Nachum Dershowitz 
 
 NSF-MCS-79-04897 
 
 
 DEPARTMENT OF COMPUTER SCIENCE 
 UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 
 
 URBANA, ILLINOIS 
 
' 
 
THE EVOLUTION OF PROGRAMS: PROGRAM ABSTRACTION AND INSTANTIATION* 
 
 Nachum Dershowitz 
 
 Department of Computer Science 
 
 University of Illinois 
 
 Urbana, IL 61801 
 
 June 1981 
 
 *Research supported in part by the National Science Foundation under grant 
 MCS-79-04897. 
 
ABSTRACT 
 
 Our goal is to develop techniques for abstracting a given set of 
 programs into a program schema and for instantiating a given schema to satisfy 
 concrete specifications. Abstraction and instantiation are two important 
 phases in software development that allow programmers to apply knowledge 
 learned in the solution of past problems when faced with a new situation. For 
 example, from two programs using the binary-search method, one to compute quo- 
 tients and another to compute cube-roots, an abstract schema can be derived 
 that embodies the shared method and that can be instantiated to solve similar 
 new problems. 
 
 We suggest the formulation of analogies as a basic tool in program 
 abstraction. An analogy is first sought between the specifications of the 
 given programs; this yields an abstract specification that may be instantiated 
 to any of the given concrete specifications. The analogy is then used as a 
 basis for transforming the existing programs into an abstract schema that 
 represents the embedded technique, with the invariant assertions and correct- 
 ness proofs of the given programs helping to verify and complete the analogy. 
 A given concrete specification of a new problem may then be compared with the 
 abstract specifications of the schema to suggest an instantiation of the sche- 
 ma that yields a correct program. These methods appear to be amenable to im- 
 plementation. 
 
 A collection of program schemata is included in an appendix. 
 
 Keywords: abstraction, instantiation, program schemata, analogy, transforma- 
 tions, program manipulation, program development, program correctness 
 
 CR Categories: 3.62, 4.43, 5.24 
 
Digitized by the Internet Archive 
 in 2013 
 
 http://archive.org/details/evolutionofprogr1011ders 
 
- 2 - 
 I. INTRODUCTION 
 
 Chaque verite que je trouvais etant une regie qui me servait apres a 
 en trouver d'autres, non seulement je vins a bout plusieurs que 
 j'avais jugees autrefois tres difficiles, mais il me sembla aussi, 
 vers la fin, que je pouvais determiner, en celles meme que 
 j'ignorais, par quels moyens, et jusques ou, il etait possible de 
 les resoudre. 
 
 - Rene Descartes, Discours de la Methode 
 
 When confronted with a task, one often perceives some measure of 
 resemblance between the given task and a previously accomplished one. In such 
 a case, rather than "reinvent the wheel," one is likely to conserve effort by 
 adapting the known solution of the old problem to the problem now at hand. 
 After having solved several similar problems, one might come to formulate a 
 general paradigm for solving such problems by highlighting the shared aspects 
 of the individual instances and supressing their inconsequential or idiosyn- 
 cratic particulars. The process of formulating a general scheme from concrete 
 instances is termed abstraction ; that of applying an abstract scheme to a par- 
 ticular problem is termed instantiation . 
 
 Abstraction and instantiation are two phases in the evolutionary 
 cycle of many typical programs, a cycle that, in addition, often includes the 
 debugging of early versions, modifications to meet amended specifications, and 
 extensions for expanded capabilities. The more experience a programmer has 
 had, the more programming methods he is likely to have assimilated, and the 
 more judiciously he can apply them to new problems. After having written 
 several similar programs, a programmer is apt to formulate for himself — and 
 
- 3 - 
 
 perhaps for others as well — an abstract notion of the underlying principle 
 and reuse it in solving related problems. Program schemata are a convenient 
 form for remembering such programming knowledge. A schema may embody basic 
 programming techniques or specialized strategies for solving some class of 
 problems; its input-output specifications are stated in terms of abstract 
 predicate, function, and constant symbols. 
 
 Our goal is to formalize this aspect of programming by developing 
 automatable techniques for abstracting a given set of concrete programs into a 
 program schema and for instantiating a schema to satisfy a given concrete 
 specification. The programs are assumed to be annotated with an output 
 specification (stating the desired relationship between the input and output 
 variables upon termination of the program), an input specification (defining 
 the set of legal inputs on which the program is intended to operate) , and 
 invariant assertions (relations that are known to always hold at specific 
 points in the program for the current values of variables) demonstrating its 
 correctness. 
 
 To date there has been a limited amount of research on program 
 abstraction. The STRIPS system (Fikes, Hart, and Nilsson [1972]) generalized 
 the loop-free robot plans that it generated; the HACKER system (Sussman 
 [1975]) "8ubroutinized" and generalized the "blocks-world" plans it syn- 
 thesized, executing the plan to determine which program constants could be 
 abstracted. Dershowitz and Manna [1975] suggest using the proof of correct- 
 ness of a program to guide the abstraction process. 
 
- A - 
 
 A number of researchers have dealt with the use of program schemata. 
 Dijkstra [1972] maintains that theorems about schemata are unconsciously 
 invoked by the programmer. Wirth [1975] illustrates the use of basic schemata 
 in the systematic development of programs. Gerhart [1975], Gerhart and 
 Yelowitz [1976], and Yelowitz and Duncan [1977] have all advocated and illus- 
 trated the use of schemata as a powerful programming tool. Other examples of 
 the use of abstract algorithms as first steps in the development of programs 
 are Darlington [1978], Deussen [1979], Duncan and Yelowitz [1979], and Lee, 
 deRoever, and Gerhart [1979]. In a similar vein, Plaisted [1980] demonstrates 
 how abstractions may be used, with great effectivity, for theorem proving. An 
 approach to the specification and verification of program schemata is given in 
 Misra [1978]. 
 
 We suggest the formulation of analogies as a basic tool in program 
 abstraction. First, an analogy is sought between the output specifications of 
 the given programs. This yields an abstract output specification that may be 
 instantiated to any of the given concrete specifications. The analogy is then 
 used as a basis for transforming the existing programs into an abstract schema 
 that represents the embedded technique. The invariant assertions and correct- 
 ness proofs of the given programs are used to extend and complete the analogy. 
 
 A schema, derived in this manner, is usually not applicable to all 
 possible instantiations of its specifications. In that case, the schema Is 
 accompanied by an input specification containing conditions that must be 
 satisfied by the instantiation in order to guarantee correctness. These 
 
- 5 - 
 
 preconditions may be derived from the verification conditions or correctness 
 proof of the schema. The abstract specifications of the schema may then be 
 compared with a given concrete specification of a new problem. By formulating 
 an analogy between the two specifications, an instantiation is found that 
 yields a concrete program when applied to the schema. If the instantiation 
 satisfies the preconditions, then the correctness of the new program is 
 guaranteed. If not, analysis of the unsatisfied conditions may suggest modif- 
 ications that will lead to a correct program. 
 
 The importance of analogical reasoning has been stressed by many, 
 from Descartes to Polya. For a review of psychological theories of analogical 
 reasoning see Sternberg [1977]. The use of analogy in automated problem solv- 
 ing in general, and theorem proving in particular, was proposed by Kling 
 [1971]. Other works employing analogy as an implement in problem solving 
 include Brown [1976], Chen and Findler [1976], McDermott [1979], and Winston 
 [1980]. Using analogies to guide the modification of programs has been inves- 
 tigated by Manna and Waldinger [1975], Dershowitz and Manna [1977], Ulrich and 
 Moll [1977], and Dershowitz [1978]. 
 
 In the next section we present several illustrations of our 
 approach. Some schemata that have appeared in the literature are collected In 
 the Appendix. 
 
- 6 - 
 II. EXAMPLES 
 
 This section contains three detailed examples of program abstraction 
 and instantiation. Each example begins with two concrete programs, annotated 
 with their specifications and invariant assertions. Then, the programs are 
 abstracted to obtain a more general program schema. Finally, each schema is 
 instantiated to satisfy a third concrete specification. 
 
 Example 1: Extremum Schema 
 
 Consider the following program: 
 
 P i : begin 
 
 comment minimum value program 
 
 assert nelN 
 
 (z,i) := (A[0],0) 
 
 loop assert z<A[0:i], ielN 
 
 until i=»n 
 
 1 := i+1 
 
 if A[i]<z then z := A[l] fi 
 
 repeat 
 assert z<A[0:n] 
 end, 
 
 where U is the set of nonnegative integers and for predicate a the construct 
 a[u:w] is shorthand for (VveZ)(u<v<w)a(v) , i.e. a holds for all integers 
 between u and w. The output specification of this program is given in the 
 statement 
 
- 7 - 
 assert z<A[0:n]; 
 
 it states that upon termination of program P^ the value of z is less than or 
 equal to any value appearing in the array segment A[0:n]. The input specifi- 
 cation of this program is given in the initial assertion 
 
 assert nelN; 
 
 it states that the value of the input variable n must be a nonnegative 
 Integer. The statement 
 
 assert z<A[0:i], ieIN 
 
 at the head of the loop contains two relations — invariant assertions — that 
 hold for the current values of the variables i and z each time control reaches 
 that point in the program. The invariants are first made true by the multiple 
 assignment 
 
 (z,i) := (A[0],0). 
 
 The two loop-body statements 
 
 i := i+1 
 
 if A[i]<z then z := A[i] fi 
 
 maintain the truth of the invariants, i.e. assuming that the invariants are 
 true before the statements are executed, the invariants remain true after- 
 wards. The loop body is repeated (zero or more times) until the test 
 
 until i-n 
 
 becomes true; at that point the loop is left, and the output specification 
 holds. 
 
 The second program is 
 
- 8 - 
 
 Qi: begin 
 
 comment maximum position program 
 assert k,JteZ, k<l 
 
 (P,j) :- (*,*) 
 
 loop assert B[p] >B [ j : X] , p.jeZ 
 while j>k 
 
 j :- j-l 
 
 if ~l(B[p]>B[j]) then p := j fi 
 
 repeat 
 assert B[p]>B[k:£] 
 end, 
 
 where Z is the set of all integers. This program finds the position p of a 
 maximal element in the array segment B[k:A]; its output specification is 
 
 assert B[p]>B[k:A] . 
 
 Its input specification 
 
 assert k,£eZ, k<£ 
 
 requires that the two input variables k and A be integers and that k not be 
 greater than A so that the array segment B[k:£] is nonempty. 
 
 Both programs perform a linear search for an extremum in an array 
 segment. Our task is to extract an abstract version of these two programs 
 that captures the essence of the technique used, but that is not specific to 
 either problem. The resultant schema can then be used as a model of linear 
 search for the solution of future problems. 
 
 The first step in abstracting these two programs is to find an anal- 
 ogy between their respective output specifications, z<A[0:n] and B[p]>B [k: I] . 
 The obvious analogy is that where the specification of Pj has 0, n, <, A, and 
 z, the specification of Qi has k, I, >, B, and B[p], respectively. This anal- 
 ogy is denoted by 
 
- 9 - 
 
 «-► k 
 
 n <— ► I 
 
 < +-► > 
 
 A -*-♦ B 
 z *-*- B[p] . 
 
 Now abstract entities may be substituted for analogous parts. Each pair in 
 the analogy is replaced by an abstract variable of the same kind: the scalar 
 constant in P^ and the corresponding scalar input variable k in Q^ may be 
 replaced by an abstract input variable <; the corresponding input variables n 
 and X may be replaced by \; the predicate constants < and > are abstracted to 
 a predicate variable a; the input arrays A and B generalize to A; and the 
 variable z and variable expression B[p] generalize to a program variable \l. 
 (We shall use Greek letters to distinguish all abstract entities.) 
 
 Applying the transformations 
 
 -► K 
 
 n -+ X 
 
 < -»• a 
 
 A -*> A 
 
 z -* u 
 
 to the output specification of Pj yields the abstract specification 
 
 assert <x(h,A[k:\] ). 
 
 Such a set of transformations is called an abstraction mapping . The abstrac- 
 tion mapping 
 
- 10 - 
 
 a — ► k 
 I -*■ \ 
 > -* a 
 B -* A 
 p -► pos(A,u), 
 
 where pos(A,|i) is a function that returns the position of some occurrence of [i 
 in the array A, yields 
 
 assert a(A[pos( A,u) ] ,A[<:\] ) 
 
 when applied to the output specification of Qi . This simplifies to the same 
 abstract specification 
 
 assert a(u,A[<:\]), 
 
 since by definition A[pos(A,u) ]=u. 
 
 In general there are several possible ways in which an expression of 
 the form f(q,r) can be compared with an expression h. If h is of the form 
 g(s,t), then the imitating mapping f-*g, q— »-s, and r— *-t suggests itself. If f 
 has an inverse f in its first argument, i.e. f(f (u,v),v)=u, then the invert- 
 ing mapping q— »-f (h,r) would work. If f has an identity element f in its 
 first argument, i.e. f(f ,v)=v, then the collapsing mapping q— »-f and r— ►h is 
 possible. Another possibility is the projecting mapping f—*% and r— ►h, where 
 % projects its first argument, i.e. ti(u,v) sb u. (Similar mappings work for 
 other than the first argument.) For a discussion of a second-order pattern- 
 matcher that uses imitating and projecting mappings and its application to 
 program manipulation see Huet and Lang [1978]. 
 
 In our example, to compare z<A[0:n] with B[p]>B[k: I] , the imitating 
 mapping O*— »-a, n«-+-b, and z<A[u]«— *[p] >B[u] is first used (eliminating the 
 quantifiers [0:n] and [k:A]). To compare z<A[u] with B[p]>B[u], another imi- 
 tating mapping, viz. <■*—►>, z«— >B[p], and A[u]+->B[u], is used. An inverting 
 mapping is needed, for example, to abstract B[p] into \i for Qj : since B is 
 abstracted into A, we need to map A[p] into [i; since pos is an inverse of the 
 
- 11 - 
 
 array access function, we get p— ►pos(A,u) . An example of a projecting mapping 
 would be A— *it and p— *-[i. 
 
 The next step in abstracting Pi and Qj is to apply the mappings to 
 the corresponding programs. Applying the first set of transformations to P^ 
 yields 
 
 S i : begin 
 
 comment tentative extremum schema 
 
 suggest XeIN 
 
 (u,i) := (A[<],<) 
 
 loop suggest a(n,A[<:i]), ieIN 
 
 until i=\ 
 
 i := i+1 
 
 if A[i]<u then u := A[i] fi 
 
 repeat 
 suggest a(u,A[<:\] ) 
 end. 
 
 Had all the transformations been of variables, as are n— ►X, A— »-A, and z— *\i, 
 then applying the transformations to all occurrences of those variables in the 
 annotated program would of necessity have resulted in a correct schema. But 
 since the abstraction mapping involves the transformation of constant symbols 
 as well, viz. and <, this schema is not necessarily correct. We have there- 
 fore replaced the assertions with "suggestions" containing those relations 
 that we would like to be invariants. 
 
 In general, a global transformation, where an input variable (e.g. n 
 or A) is systematically replaced — in the assertions as well as in the code 
 — by some function of only input variables, will always yield a program (or 
 program schema) that satisfies the transformed input-output specifications. 
 Similarly, systematically replacing a program (or output) variable (e.g. z) by 
 a function of (input or program) variables preserves correctness with respect 
 to the specifications. However, global transformations of constants (e.g. 
 and <) might be overzealous or Incomplete, and they are not guaranteed to 
 result In a program satisfying the specifications. That is because the 
 
- 12 - 
 
 correctness of the original program may have depended on properties of these 
 constants that do not hold for their transformed counterparts. There could, 
 for example, be unrelated occurrences of in Pj , say for the purpose of 
 illustration that the exit test were i+0=X or that there was an additional 
 loop-body assignment i:=i+0, in which cases the transformation 0— *■< would be 
 inappropriate. Or the predicate symbol < might not appear explicitly in the 
 program code at all, as indeed it does not, in which case the transformation 
 <— *-a would be insufficient. 
 
 One must therefore examine the schema's verification conditions to 
 determine under what assumptions the suggestions may in fact be invariants. 
 First, consider the loop-exit path 
 
 suggest a(u,A[<:i]), ielN 
 
 assert i=\ 
 
 suggest a(u,A[<:\]). 
 
 (The first suggestion is the transformed loop invariant that we are assuming 
 was true when control was last at the head of the loop; the second statement 
 asserts that the exit test was true at that time and therefore the loop was 
 exited; the final suggestion contains the desired output relations with 
 respect to which we are trying to prove this schema correct.) For this path to 
 be correct, the loop invariants in the first suggestion, together with the 
 exit test of the assertion, must imply that the desired output relation in the 
 second suggestion holds, i.e. the verification condition for the exit path is 
 
 a(u,A[<:i]) A ielN A i=X D a(u,A[ic:X] ). 
 
 Indeed, if a(u,A[<:i]) holds and i=\, then a(u,A[<:\]) holds as well. Thus, 
 if we can establish that a(|i,A[<:i] ) and IelN are loop invariants, then the 
 schema is correct. 
 
 Next, we consider the initialization path 
 
- 13 - 
 
 suggest XeIN 
 
 (|i,I) := (A[<],<) 
 
 suggest a(u,A[tc:i] ), ielN. 
 
 Its verification condition is 
 
 \e!N 3 <x(A[k],A[k:k]) A <elN. 
 
 (This condition Is obtained from the path by substituting the new values A[<] 
 and < assigned to the variables n and I, respectively, for occurrences of the 
 variables in the suggestion following the assignment.) The subterm A[<:<] sim- 
 plifies to A[<]. For cosmetic purposes, we shall replace the expression A[<] 
 in oc(A[k] ,A[<] ) by the universally quantified u and just write a(u,u), i.e. a 
 must be reflexive. Since there is no way of showing 
 
 or 
 
 ct(u,u) 
 
 to hold, they are both left as preconditions for the schema to be correct. 
 
 The loop-body path verification condition is composed of two cases, 
 one for each possible outcome of the conditional test. In the case when the 
 test fails, the then-branch is skipped: 
 
 suggest a(u,A[<:i]), iclN 
 
 assert ~ |(i=*\ ) 
 
 i :- 1+1 
 
 assert ~l(A[i]<u) 
 
 suggest a(u,A[<:i]), ielN. 
 
 To verify this path we must show that the loop invariants continue to hold if 
 the exit test is false, i is incremented, and the conditional test is false. 
 The corresponding verification condition is 
 
- 14 - 
 a(n,A[<:i]) A lelN A l(i=\) A ~l(A[i+l]<u) D a(u,A[«:i+l] ) A i+leU. 
 
 Clearly, if IelN before executing i:-i+l, then ielN after, i.e. ielN 
 implies i+lelN. We must also show a([i,A[<:i+l] ). But it is already assumed 
 that a(u,A[ic:i] ); all that remains to show is a(u,A[i+l]). The only possibly 
 relevant assumption (relating u and A[i+1]) is ~~|(A[i+l] <u), i.e. ~|(A[i+l]<u) 
 should imply a(u,A[i+l] ). Of course, since a is an abstract predicate, there 
 is no reason for that to be the case. Accordingly, we look for an abstraction 
 mapping that will unify the two relations: 
 
 ~l(A[i+l]<u) - <x(u,A[i+l]). 
 
 Inverting gives 
 
 A[i+1]<^ -» "|a(u,A[i+l]); 
 
 imitating leaves 
 
 u<v -* ~1a(v,u) . 
 
 Applying this additional transformation to (the loop body of) the 
 schema, we get the conditional statement 
 
 if ~|a(u,A[i]) then \x := A[i] fi. 
 
 Now the verification condition for the case when the test is false carries 
 through, and it remains to verify the other case when ~~ |a(|i,A[i] ) is true: 
 
- 15 - 
 
 suggest a(u,A[ic:i] ), ielN 
 
 assert ~|(i=X) 
 
 i := i+1 
 
 assert |cx (|i , A [ i ] ) 
 
 u := A[i] 
 
 suggest ct(u,A[ic:i] ), ielN. 
 
 The verification condition for this case is 
 
 a(u,A[i<:i]) A ielN A ~|(i=X) A ~|a(ji,A[i+l] ) D a(A[i+l] ,A[tc:i+l] ) A i+lelN. 
 
 Again, the invariant ielN is clearly maintained, and since we are already 
 assuming that a is reflexive, i.e. a(A[i+l] ,A[i+l] ) , we need only ascertain 
 a(A[i+l] ,A[<:i] ). Since there is no way to prove this to hold for all a, it 
 is left as a precondition: 
 
 a(n,A[<:i]) A ielN A ~l(i=X) A ~la(u,A[i+l] ) Z> a(A[i+l] ,A[<:i] ) 
 
 For convenience, we shall replace this with (the more general condition) 
 
 a(w,u) A ~|a(w,v) 3 a(v,u). 
 
 Finally, we consider the verification condition for termination: 
 
 \e!N D GuelN)K+u=\ 
 
 (i.e. the exit test i=*\ will eventually hold for some value k+u of i) . Since 
 K,\elN is assumed to hold (XeIN appears in the suggested input specification 
 and keIN is a precondition), this termination condition is equivalent to 
 
 <<X. 
 
 This too is left as a precondition. 
 
- 16 - 
 Applying the complete abstraction mapping 
 
 -► K 
 n -*■ \ 
 
 < -* a 
 
 A -► A 
 
 z -* [i 
 
 u<v — ► ~|a(v,u) 
 
 to program P^ , our final version of the schema is 
 
 S} : begin 
 
 comment extremum schema 
 
 assert a(u,u), a(w,u) A~la(w,v)2) a ( v » u ) > <AelN, <<K 
 
 (u,i) := (A[k],k) 
 
 loop assert a(n,A[<: i] ) , ielN 
 
 until i-X 
 
 i := i+1 
 
 if la(u,A[i]) then \x := A[i] fi 
 
 repeat 
 assert a( \i , A [ < : \ ] ) 
 end. 
 
 Now that we have verified the conditions for each of the paths in the program, 
 the suggestions have been replaced by assertions. The preconditions are given 
 in the input assertion; any instantiation that satisfies them is guaranteed to 
 yield a correct program. Obviously, the predicate a that appears in the 
 schema should be instantiated to a primitive predicate available in the target 
 language; otherwise it must be replaced by something equivalent for the schema 
 to yield an executable program. Likewise, the constants A, tc, and X must be 
 replaced with primitives. 
 
 Recall that the given output specification of program ?i was 
 
- 17 - 
 assert z<A[0:n] . 
 
 Actually, a more realistic specification for a search for a minimum would have 
 included the relation zeA[0:n], i.e. not only should z be no larger than any 
 element of A[0:n], but it should be one of those elements. If we apply the 
 abstraction mapping that we have found to this additional specification as 
 well, we get the abstract relation neA[ic:\] which indeed may be shown to hold 
 for the schema we have derived. We also note that had we applied the 
 corresponding abstraction mapping to Qi instead of to P], a somewhat dif- 
 ferent, but equally valid, schema would have resulted. 
 
 The schema S^ can be instantiated to find the position or value \i of 
 either the minimum or maximum of any function A over some domain of nonnega- 
 tive integers in the range [<:\]. For instance, say we want to find the posi- 
 tion m of the minimum of some function f for the odd integers in the interval 
 [1:100]. Comparing this goal 
 
 achieve (Vue[l :100] )(odd(u)3f (m)<f (u) ) 
 
 with the abstract output specification of the schema 
 
 assert a( \i , A [ < : X ] ) , 
 
 suggests first applying the imitating mappings <— »-l, \-»-100, and 
 a(u,A[u] )— »-odd(u)3f (n0*f (u) • The last of these mappings can be accomplished 
 by the projecting and imitating mappings A— Ht, a(v,u)— ►oddCu)^^ ( v )*f ( u ) » an< ^ 
 H— *-m, where n is the identity function. 
 
 Applying the instantiation mapping 
 
- 18 - 
 
 K -* 1 
 
 \ -► 100 
 
 A -*> it 
 
 a(v,u) -► odd(u)3f(v)<f(u) 
 
 p, — ► m 
 
 to the preconditions 
 
 a(u,u) 
 a(w,u) A ~|a(w,v) Z) <*(v,u) 
 
 yields 
 
 l,100elN 
 
 odd(u) Z> f(u)<f(u) 
 
 |"odd(u)Df(w)<f(u)l A ~irodd(v)I)f(w)<f(v)l 3 fodd(u)I)f(v)<f (u)l 
 
 K100. 
 
 The first and last conditions are obviously true; the second holds since < is 
 reflexive; the third follows from transitivity. Applying the above instantia- 
 tion mapping to the schema yields 
 
 Rl : begin 
 
 comment function minimum program 
 
 (m,i) :- (1,1) 
 
 loop assert (Vue[l: i] )(odd(u)I)f (m)<f (u) ), ielN 
 
 until i=100 
 
 i := i+1 
 
 if odd(i)Af(i)<f(m) then m := i fi 
 
 repeat 
 assert ( Vue[l: 100] )(odd(u)I)f (m)<f (u)) 
 end. 
 
 (The transformed conditional test ~|(odd(i)3f (m)<f (i) ) simplifies to 
 
- 19 - 
 odd(i)Af(i)<f(m).) 
 
 Since the preconditions were satisfied by the instantiation, this 
 program is guaranteed to be correct. Further improvements to the instantiated 
 program can be made (e.g. incrementing i by two) by a straightforward series 
 of program transformations such as those catalogued in Standish, et al. 
 [1976]. 
 
 Example 2: Binary-Search S chema 
 
 The following two programs both use the binary-search technique. 
 The first program 
 
 P2 : begin 
 
 comment real division program 
 
 assert 0<c<d, e>0 
 
 (q,y) :- (0,1) 
 
 loop assert q<c/d, c/d<q+y 
 
 until y<e 
 
 y := y/2 
 
 if d*(q+y)<c then q := q+y fi 
 repeat 
 
 assert |q-c/d|<e 
 end 
 
 uses that technique to find the quotient q of two nonnegative real numbers c 
 and d, c<d, within a given positive tolerance e. The second program 
 
- 20 - 
 
 Q 2 : begin 
 
 comment cube-root program 
 assert x>l, t>0 
 
 (r,w) :- (l,x) 
 
 „ 1/3 1/3^ 
 loop assert r<x , x <w 
 
 while w-r>t 
 
 s := (w+r)/2 
 
 else w := s fl 
 
 3 
 if s <x then r := s 
 
 repeat 
 
 I 1 /3 i , 
 assert | r-x | <t 
 
 end 
 
 finds the cube root r of the real number x, x>l, within positive tolerance t. 
 
 In comparing their respective output specifications, an obvious 
 analogy is 
 
 q «— ► r 
 u/d «-* u 
 c •*-► X 
 
 e «— > t. 
 
 If we apply the abstraction mapping 
 
 q - I 
 
 u/d -*■ <J)(u) 
 
 c -*> p 
 
 e -► e 
 
 to P2» we obtain the schema 
 
- 21 - 
 
 S2 : begin 
 
 comment tentative binary-search schema 
 
 suggest 0<p<d, e>0 
 
 (F,y) := (0,1) 
 
 loop suggest !;<<(>( p), 4>(p)<£+y 
 
 until y<e 
 
 y := y/2 
 
 if dx(£+y)<p then I := £4y fi 
 
 repeat 
 suggest |^-<j>(p)|<e 
 end. 
 
 As In the previous example, we have replaced the assertions with suggestions 
 to indicate that this schema may be incorrect. 
 
 This time, rather than look just at verification conditions, we ima- 
 gine that the programmer has supplied detailed comments on the reasoning he 
 employed in constructing P2 and O^. Such additional information may help in 
 extending the analogy between the programs and arriving at a correct schema. 
 It may also allow the localization of transformations to relevant occurrences 
 of symbols and will help avoid unnecessarily strict preconditions. 
 
 The output specification of P2 was 
 
 assert |q-c/d|<e. 
 
 The programmer achieved the desired relation |q-c/d|<e by decomposing it into 
 the three conjunctive subgoals given in the 
 
 purpose q<c/d, c/d<q+y, y<e. 
 
 (This is just a comment left by the programmer listing the relations he meant 
 
 his code to achieve.) The last conjunct became the exit test of the loop and 
 
 the other two became loop invariants. Abstracting these subgoals, by applying 
 the mapping, gives 
 
- 22 - 
 purpose £<<J>(p), <Kp)<S+y, y<e» 
 
 which indeed imply (and are all needed to imply) the desired output specifica- 
 tion of the schema |2;-<j>(p) |<e. 
 
 Similarly, the goal 
 
 purpose I r-x | <t 
 
 of program Q2 was reduced to the three subgoals 
 
 1/3 1/3 
 purpose r<x , x <w, ~](w-r>t) . 
 
 Applying the abstraction mapping 
 
 r -*• I 
 
 u ■* <j>(u) 
 
 x -»■ p 
 
 t -* e 
 
 to these subgoals yields 
 
 purpose Z<$( p), <t>(p)<w, ~|(w-£>e). 
 
 This is not however identical with the subgoals for P2; to make them 
 equivalent requires extending the analogy with 
 
 S+y «— ► w. 
 
 If we let ti be their abstract counterpart, then 
 
 y -* r\-Z 
 
 must be added to the abstraction mapping of P2 and 
 
- 23 - 
 
 w 
 
 to the mapping for Q2 . 
 
 There are, however, problems with applying the transformation y-*"n-£ 
 to the statements of P2« If we apply it in a straightforward manner to the 
 initialization assignment (E ,y) : = (0,1) , then we obtain (F,,t)-?;): = (0,1) . But 
 the assignment n-£:=l is illegal, as an expression such as n-^ may not appear 
 on the left-hand side of an assignment. Nevertheless, the desired effect of 
 making the difference between the new values of r\ and E equal to 1 can be 
 achieved by the legal assignment r|:=l+0, since is the new value of £. Simi- 
 larly, the transformed loop-body assignment n-!;: =(n-£)/2 is illegal. To make 
 it legal, the £ must be transposed to the right-hand side; the resulant 
 assignment is n:=(Ti+^)/2 . 
 
 We are not yet finished, however, as the value of the difference Tp£ 
 also changes whenever £ is assigned to. Accordingly, we must look at the 
 then-branch assignment £:=£+y, or rather at (5,y) :=(£+y ,y) , where we have 
 explicitly included a dummy assignment to the variable y. Transforming this 
 gives (r, ,ti-C): = (^+ti-^,ti-^). Thus, £ should get the value n and n should get 
 the value rr? plus the new value of £, i.e. the old value of n. The appropri- 
 ate legal assignment is accordingly (£,n) : = (Ti,2*n-£). 
 
 At this stage, the abstracted program is 
 
- 24 - 
 
 begin 
 
 comment tentative binary-search schema 
 suggest 0<p<d, £>0 
 a,n) :- (0,1) 
 
 loop suggest £<<t>(p), <j>(p)<n 
 until TT^<e 
 
 n := (n+O/2 
 
 if d*n<p then (S,n) :- (n,2*T)-!;) fi 
 
 repeat 
 suggest | C— <p Cp > I <e 
 end. 
 
 The initialization of the division program was correct since q=0 and 
 
 y=l imply q<c/d<q+y; the correctness of the initialization of the cube-root 
 
 1/3 
 program follows from the fact that r=l and w=a imply r<a <w. This suggests 
 
 extending the analogy with 0«-*l and 1-*— ►a and extending the abstraction map- 
 pings with 
 
 -► o <- 1 
 
 1 -* i +— x. 
 
 These transformations need only be applied to the respective initializations. 
 The resultant abstract condition for the correctness of the initialization is 
 
 o<<Kp)<i • 
 
 This is our first precondition; it replaces the abstracted input specification 
 0<p<d. 
 
 The purpose that the programmer had in mind for the loop body of P2 
 was 
 
 purpose q<c/d, c/d<q+y, 0<y<y' , 
 
- 25 - 
 
 where y' denotes the value of the variable y when control was last at the head 
 of the loop. In other words, the loop body reachleves the invariants while 
 making progress towards the exit test by decreasing y (some minimal amount — 
 to ensure termination). Abstracting this goal, or the corresponding one for 
 Q2, yields 
 
 purpose £<<K p), <Kp)<n, 0<tp5<ti'-£'. 
 
 To achieve the last conjunct of the loop-body goal, the division 
 program decreases y. Then, to achieve the remaining two conjuncts, a condi- 
 tional statement with the 
 
 purpose q<c/d, c/d<q+y 
 
 (for the decreased value of y) is introduced. Since only the value of y has 
 
 so far been changed by the loop body, q<c/d still holds, but c/d<q+y might 
 
 not. The program determines if the latter still holds by testing the 
 
 equivalent condition d*(q+y)<c It is here, however, that the correctness of 
 
 the schema breaks down: the transformed test d*n<p does not determine if the 
 
 3 
 abstract relation <J> ( p ) <n holds. Similarly, the test n <p obtained by 
 
 abstracting Q2 does not test for <t>(p)<n. 
 
 There is, nevertheless, an analogy between the tests in P2 and Q2. 
 
 3 
 where the former has the function d*u, the latter has u . Accordingly, the 
 
 analogy between P2 and Q2 is extended with 
 
 3 
 
 d*u — ► 4»(u) ■*— u . 
 
 Now, for the conditional statement to have the desired effect, we 
 need ~~I(<K(t)+0/2 )<p) to imply $(p)<(TrH r ,)/2 , or more generally 
 
 ~|((Ku)<v) Z> 4>(v)<u. 
 
 This becomes a precondition. We must also determine the conditions under 
 
- 26 - 
 
 which the then-branch of the conditional is correct. That case was correct in 
 the division program because d*(q+y/2)<c implies q+y/2<c/d and c/d<q+y implies 
 c/d<q+y/2+y/2. For the abstracted schema, then, we need <K(t)+£)/2)<p to imply 
 (n+£)/2<<Kp) and <Kp)<T) to imply <Kp)<2*(n+S)/2-£. The second implication 
 obviously holds; the first yields the precondition 
 
 <l>(u)<v D u<<|>(v). 
 
 Combined with the previous precondition, we have 
 
 4»(u)<v = u<<|>(v) , 
 
 which holds, in particular, if <\> is the inverse of a monotonic function <f>, 
 i.e. if <()((p(u)) ! »u and u<v=<t>(u)<<J>(v) • 
 
 Putting everything together, the complete abstraction mapping for P2 
 is 
 
 u/d -»• 4>(u) 
 
 c -»• p 
 
 e -*■ e 
 
 dx u -► 4>(u) 
 
 y -*> rrl 
 
 -+ o 
 
 1 -► 1 
 
 and we have derived the schema 
 
- 27 - 
 
 begin 
 
 comment binary-search schema 
 assert (Ku)<v=u<<t>(v) > o<<t>(p)<i, £>0 
 (E,n) := (0,1) 
 loop assert £<<t>(p), <t>(p)<ri 
 until tt£<£ 
 
 n := (n+C)/2 
 
 if <Kn)<p then (F,,n) := (n,2*r,-5;) fi 
 
 repeat 
 assert |£-<J>(p)|<e 
 end. 
 
 This schema may be slightly optimized by applying the correctness- 
 preserving global transformation n— ^-Hi. The schema 
 
 S 2 : begin 
 
 comment binary-search schema 
 assert <Ku)<v=u<<J>(v) » 0<4>(p)<i, £>0 
 (£>n) := (o,\-o) 
 loop assert £<<|>(p), <Kp)<£+ri 
 
 until n<e 
 
 Tj := n/2 
 
 if <KE+n)<p then ^ := J^+n fi 
 
 repeat 
 assert | J^— <J>(p ) | <e 
 end 
 
 that results is more similar to P2« It is a general-purpose program schema 
 that performs a binary-search for the value F, of an invertible monotonic func- 
 tion <t> at the point p within a tolerance e. 
 
 We show now how this binary-search schema may be applied to the com- 
 putation of integer square-roots. Our goal is to construct a program that 
 sets the value of a variable z to L^nJ , where nelN and (_uj is the largest 
 integer less than or equal to u. This attempt will illustrate some of the 
 
- 28 - 
 difficulties that may arise in trying to apply a schema. 
 
 In this case, we cannot directly match our goal 
 
 achieve z=j_/nj varying z 
 
 with the output specification of the schema 
 
 assert |e-<(>(p) |<e. 
 
 To bring out the analogy we must first expand the goal z^L/nj using the 
 definition of j_uj , giving the equivalent goal 
 
 achieve z</n, /n<z+l, zeZ. 
 
 Since we know that the schema also achieves the two output invariants 
 
 assert £<<K p), <KpK5+e> 
 
 we can compare these invariants with our goal* This suggests the instantia- 
 tion mapping 
 
 S - z 
 <t> -* /"" 
 
 p -* n 
 
 e -► 1 
 
 to achieve the first two conjuncts of the goal. In addition we will have to 
 somehow achieve zeZ. 
 
 The preconditions for the schema's correctness are 
 
 assert 4>(u)<vEu<<t>(v) , o<<Kp)<i; 
 
 instantiating them yields 
 
- 29 - 
 
 4>(u)<vEu</v, o</n<i . 
 
 2 
 Since u <v is equivalent to u</v when u>0, the first condition may be satis- 
 
 2 
 fied by taking 4>(u) to be u , provided that the argument u is never negative. 
 
 Noting that /n>0 suggests letting o=0; /n<i can be satisfied by letting \=n+l. 
 
 This all suggests completing the instantiation to obtain 
 
 % 
 
 — ► z 
 
 4> 
 
 -* r 
 
 P 
 
 -*■ n 
 
 <Ku) 
 
 -*» 1 
 
 2 
 
 1 -♦ u 
 
 
 
 -► 
 
 i -*■ n+1. 
 
 Applying this instantiation to the schema, we obtain the program 
 
 R2 : begin 
 
 comment instantiated schema 
 
 assert nelN 
 
 (z,n) := (0,n+l) 
 
 loop assert z</n, /n<z+n 
 
 until n<l 
 
 n := n/2 
 
 2 
 if (z+n) <n then z := z+p fi 
 
 repeat 
 
 assert z</n, /n<z+l 
 
 end. 
 
 It is easy to establish that both n and z are nonnegative; thus, the condi- 
 
 2 .— 
 
 tional test r\ <n is equivalent to n</n, as required. 
 
 We are still left with achieving the subgoal zeZ. One way that 
 this may be done is by perturbing the final value of z just enough to make it 
 an Integer while preserving the two relations that the instantiated schema 
 
- 30 - 
 achieves. Accordingly, we append the statement 
 
 2 
 
 if n<([zj+l) then z :» |_ Z J 
 
 else z := L Z J +1 fl 
 
 Alternatively, zeZ could be achieved by ensuring that the assignments to z 
 preserve that relation. This avenue is pursued in Dershowitz [1978] , where a 
 series of additional transformations results in an improved version of integer 
 square-root. 
 
 Our final program is 
 
 R 2 
 
 begin 
 
 
 
 
 comment integer square-root 
 
 program 
 
 assert neIN 
 
 
 
 (z,n) 
 
 := (0,n+l) 
 
 
 
 loop 
 
 assert z</n, 
 until n<l 
 
 ti :■ n/2 
 
 , /n<z+p 
 
 
 
 if (z+n) <n 
 
 then z :■ 
 
 z+n fl 
 
 if 
 
 repeat 
 
 n<([zj+l) 2 
 
 then z :■ 
 else z := 
 
 |_zj+l fi 
 
 assert z=(_/nj 
 
 
 
 end. 
 
 
 
 
- 31 - 
 Example 3_: Associative Recursion S chema 
 
 Abstraction may also be used for the design of correctness- 
 preserving program transformations. For example, one can first write itera- 
 tive versions of several recursive programs; by abstracting those programs, a 
 more general recursion-to-iteration transformation schema can be obtained. As 
 we shall see in the following example, very little information is gleaned by a 
 comparison of output specifications; instead, most of the analogy is derived 
 from the verification conditions. 
 
 The two given programs are 
 
 P3 : begin 
 
 comment factorial program 
 
 assert nelN 
 
 (z,y) := (l,n) 
 
 loop assert y!*z=n!, yelN 
 
 until y=0 
 
 (z,y) := (yxz,y-l) 
 
 repeat 
 assert z=n! 
 end 
 
 and 
 
- 32 - 
 
 Q 3 : begin 
 
 comment summation program 
 
 assert k,meZ, k<m 
 
 (s,j) := (0,k) 
 
 loop assert T™ = f(i)+s=Z m =k f(i), jeZ 
 until j=m+l 
 (s,j) := (f(j)+s,j+l) 
 
 repeat 
 
 rl 
 end. 
 
 assert s=s ? =k f(i) 
 
 Our object is to derive a schema for computing recursive functions that are 
 like factorial and summation. 
 
 Matching the two output specifications 
 
 assert z=n! 
 
 and 
 
 assert s=Z m . f(i) 
 i=k 
 
 suggests as one possible analogy 
 
 n 
 
 u! <-► E m f(i). 
 i=u 
 
 The two output variables z and s generalize to the abstract output variable C; 
 the input variables n and k generalize to x» the two functions u! and 
 Z._ f(i) generalize to an abstract function variable 9(u). 
 
 Applying the abstraction mapping 
 
- 33 - 
 
 z -* C 
 
 n -* x 
 
 u! -► 9(u) 
 
 to P3 yields 
 
 S3: begin 
 
 comment abstracted factorial program 
 suggest yelN 
 (C,y) := (l,x) 
 
 loop suggest e(y)xc=e(y), yelN 
 until y=0 
 
 (C,y) := (y*C,y-l) 
 
 repeat 
 suggest C=Q(x) 
 end. 
 
 Applying the mapping 
 
 8 -► C 
 
 k - x 
 ^ =u f(D - e(u) 
 
 to Q3 yields a schema with the same output suggestion: 
 
 T 3 : begin 
 
 comment abstracted summation program 
 
 suggest x.meZ, x<m 
 
 CC.j) :- (0,x) 
 
 loop suggest G(j)+C»9(x), jeZ 
 until j-m+l 
 (C,j) :- (f(j)+C,j+l) 
 repeat 
 
 suggest C"6(x) 
 
 end . 
 
- 34 - 
 Neither abstract program is, however, correct. 
 
 Both programs consist of a single loop; their respective abstracted 
 loop invariants are 
 
 assert 0(y)xC=9(x)» yelN 
 and 
 
 assert G(j)+C=9( X ), jeZ- 
 Matching the invariants suggests the additional aspect of the analogy 
 
 y -* V «- j 
 
 X -*• •% +— + 
 
 IN -* Q «~ Z. 
 
 Applying the corresponding transformations to the loop invariants we obtain 
 the abstract invariant 
 
 assert T(e(v),C)=6(x)> veQ. 
 
 Now, we must consider the verification conditions. Applying the 
 transformations to the initialization condition of P3 we get 
 
 T(6( X ),i)-e(x) 
 
 on the other hand, applying the transformations to the initialization condi- 
 tion of Q3 gives 
 
 t(0(x),O)=0( X ) 
 XeQ. 
 
- 35 - 
 The shared condition 
 
 xeQ 
 
 becomes a precondition for the schema. To unify the remaining conditions of 
 the two programs we add to the analogy 
 
 1 -*• a) +- 0, 
 
 to obtain the abstract condition 
 
 T(e(x),w)-e<x), 
 
 or more generally, 
 
 t(u,go)=u. 
 This too is a precondition. 
 
 The loop-exit condition derived from P3 is 
 
 T(9(v),C)-e( X ) A veQ A v=0 3 C=e(y); 
 from Q3 , we get 
 
 t(6(v),0-9(x) A veQ A v-nrfl D C-6(x). 
 With the additional abstraction 
 
 -► y ♦- mfl 
 we get 
 
 T(e(v),C)-«(x) A veQ A v-y D C-9(x). 
 For simplicity, we shall replace this condition with the stronger 
 
- 36 - 
 t(9(y),u)=»u. 
 
 For the loop-body paths, we have the conditions 
 T(9(v),C)-e(x) A veQ A v*y D T(0(v-l),T(v,C))-e(x) A v-leQ 
 
 and 
 
 T(0(v),C)-e( X ) A veQ A v* Y D x(0(v+l),T(f(v),C))-e(x) A v+leQ, 
 
 for P3 and Q3, respectively. To unify v-l«— *v+l and v*—»-f(v), we need the 
 additional abstractions 
 
 u-1 -* 6(u) <- u+1 
 v -»■ a(v) ■*— f(v). 
 
 (The transformation v— ►a(v) applied to all occurrences of v in P3 would be 
 overzealous; it should be localized to the occurrence that led to the differ- 
 ence between the two verification conditions. That occurrence is in the 
 assignment £:=t(v,£) obtained from the original z. #si yxz.) This abstraction map- 
 ping yields 
 
 x(e(v),C)-0(x) A veQ A v* Y D x(e(6(v)),T(<y(v),C))-e(x) A 6(v)eQ, 
 
 for which we shall use the two preconditions 
 
 v* Y D t(9(v),u)=t(9(6(v)),t(o-(v),u)) 
 veQ A v#y D 6(v)eQ. 
 
 Finally, the verification condition for the termination of the 
 abstracted program is 
 
 (3uelN)6 u (x)=Y- 
 
- 37 - 
 This too becomes a precondition. 
 
 The complete abstraction is 
 
 z -+ C ■*-" s 
 
 n -► x +- k 
 
 u! - 9(u) 4- Sj. u f(l) 
 
 y -*• v 4- j 
 
 X — ► t «— + 
 
 IN -► Q <— Z 
 
 1 -► o) ««- 
 
 -+ y «- mfl 
 
 u-1 -»• 6(u) *- u+1 
 
 v -* a(v) ♦— f(v). 
 
 Applying these abstraction transformations (in order) to Q3 , and collecting 
 all the preconditions, we derive the schema 
 
 S 3 : begin 
 
 comment associative recursion schema 
 assert t(u,w)=u, t(9(y),u) s »u, 
 
 v*YZMQ(v),u)=T(e(6(v)),T(o(v),u)), 
 
 XeQ, veRAv*Y.D6(v)eQ, 
 
 (3ue3N)6 U ( X )=Y 
 (C,v) := (w,x) 
 loop assert x(9(v),C)*»9(x) > veQ 
 
 until v»y 
 
 (C,v) :- (T(a(v),C),6(v)) 
 
 repeat 
 assert C"9(x) 
 end. 
 
 In this manner we have obtained a general schema for computing a 
 function 9(x). It applies to recursive functions 9(x) such that 9(y)™w is a 
 unit of an associative and commutative function x, and 9(u)°t(9(6(u) ) ,o(u) ) 
 
- 38 - 
 
 when i#y The schema is similar to one of the recursion-to-iteration 
 transformations of Darlington and Burstall [1978]. 
 
 To see how this schema may be applied to another problem, consider 
 the specifications 
 
 R3 : begin 
 
 comment list-reversal program 
 
 assert lei 
 
 achieve z=reverse(J? ) varying z 
 
 end, 
 
 where L is a set of lists and reverse(X) is the list containing the elements 
 of I in reverse order. Assume that we are also given two relevant facts about 
 reverse: reverse( ())=■() , where () is the empty list, and 
 reverse(u)=rever8e(tail(u) )*(head(u) ) when u*(), where u*v concatenates the 
 two lists u and v, (head(u)) is a one element list containing the first ele- 
 ment of u, and tail(u) is a list of all but the first element. 
 
 An initial comparison of the schema's output specification C = 9(x) 
 with the new specification z=reverse(A) suggests the instantiation 
 
 9 -+■ reverse 
 C -*• z 
 X - *• 
 
 Instantiating the precondition 
 
 v#Y D T(9(v),u)-T(e(6(v)),T(o(v),u)) 
 
 gives 
 
 v*Y 3 x(reverse(v) ,u) s »T(reverse(6(v)),x(a(v) ,u) ). 
 
 By the second of the above two facts, we have that reverse(v) may be replaced 
 by reverse(tail(v))*(head(v)), provided that v is not the empty list (). This 
 
- 39 - 
 
 suggests the possibility of instantiating y— ► () to obtain 
 
 v* ( ) D t(reverse( tail( v) )*(head(v) ) ,u)=-t(reverse(6 (v) ) ,t(o(v) ,u) ) . 
 
 The function reverse appears on the two sides of the equality, so we try to 
 generalize this condition by replacing both occurrences of reverse with an 
 arbitrary list w. (This is similar to the generalization technique used in 
 the theorem prover described in Boyer and Moore [1980].) To do that, we must 
 first unify reverse(6(v)) with reverse(tail(v) ) by instantiating 6— »-tail. We 
 are left with 
 
 v*() D x(w*(head(v)),u)=T(w,T(a(v) ,u)). 
 
 Similarly, we unify a(v) with (head(v)), the list containing just the first 
 element of v, obtaining 
 
 v*() Z) x(w*v,u)=t(w,t(v,u)). 
 
 This matches with the fact that * is associative, i.e. (w*v)*u=w*(v*u) , by 
 instantiating t-*-*. 
 
 Applying the instantiations that we have found to the other five 
 preconditions 
 
 t(u,w)=u 
 t(6(y),u)=u 
 
 veQ A v*y D Mv)eQ 
 (3ueIN)6 U (x)=Y 
 
 yields 
 
- 40 - 
 
 U*0)=*U 
 
 reverse( ())*u=u 
 
 veQ A v*() D tail(v)eQ 
 (3uelN)tail U (JD=(). 
 
 But reverse( ())=() and ()*u=u, since the empty list () is an identity element 
 of the function *. Thus, the second condition holds. The first suggests let- 
 ting ar-^O; the third and fourth suggest letting Q-*L. The last condition 
 then follows from the third, as a property of lists. 
 
 The completed instantiation is 
 
 -*■ reverse 
 
 C -► z 
 
 X -* r 
 
 Y -► () 
 
 6 -► tail 
 
 a(u) -» (head(u)) 
 
 T -► * 
 (d - (). 
 
 In all, we have derived the following program 
 
 R-3 : begin 
 
 comment list reversal program 
 
 assert £eL 
 
 (z,v) :- ((),*) 
 
 loop assert reverse(v )*z=»reverse(A) , veL 
 
 until v*() 
 
 (z,v) := ((head(v))*z,tail(v)) 
 
 repeat 
 assert z=reverse(A) 
 end. 
 
- 41 - 
 
 In this example most of the instantiation mapping was derived from 
 an analysis of the preconditions. The preconditions served, In this way, to 
 guide the construction of the list-reversal program in the pattern of other 
 recursive functions. 
 
 
- 42 - 
 III . DISCUSSION 
 
 We have presented several examples demonstrating a methodology for 
 deriving an abstract program schema that captures the technique underlying a 
 given set of concrete programs. Once derived, the schema may be applied to 
 solve new problems by instantiating the abstract entitites of the schema with 
 concrete elements from the problem domain. We have also seen how this metho- 
 dology can be used to derive correctness-preserving program transformations 
 and to guide their application. 
 
 Abstraction and instantiation complement techniques of program 
 transformation, such as have been advocated by Knuth [1974]. When faced with 
 the task of developing a new program (or subprogram) to meet a set of specifi- 
 cations, the programmer ought to first search for an applicable schema. After 
 instantiating the schema, transformations may be applied to solve any remain- 
 ing specifications or to increase efficiency. If no applicable schema can be 
 found, one might still be able to find a schema or program solving some analo- 
 gous problem, and modify it (see, for example, Dershowitz and Manna [1977]). 
 The two programs together would then be used to formulate a schema for future 
 use. 
 
 There are a few problems inherent in the use of analogies for pro- 
 gram abstraction and instantiation. These include "hidden" analogies, 
 "misleading" analogies, "incomplete" analogies, and "overzealous" analogies. 
 
 Hidden analogies arise when given specifications (of the two or more 
 existing programs in the case of abstraction, and of the abstract schema and 
 concrete problem in the case of instantiation) that are to be compared with 
 one another have little syntactically in common. Since the pattern-matching 
 ideas that we have employed are syntax based, when the specifications are not 
 syntactically similar, the underlying analogy would be hidden. In such a 
 situation it is necessary to rephrase the specifications in some equivalent 
 manner that brings their similarity out, before an analogy can be found. This 
 is clearly a difficult problem in its own right; in general some form of 
 means-end analysis seems appropriate. 
 
- 43 - 
 
 At the opposite extreme, a syntactic analogy may be misleading. The 
 same symbol may appear in the specifications of two programs, yet may play 
 nonanalogous roles in the two programs. Two programs might even have the 
 exact same specifications, but employ totally different methods of solution. 
 Situations such as these would be detected in the course of analyzing the 
 correctness conditions for the abstracted programs. 
 
 We have seen how the proof of correctness of a program can be used 
 
 to help avoid overzealously applying transformations to unrelated parts of a 
 
 program. The proof also helps complete an analogy between two programs, only 
 part of which was found by a comparison of specifications. 
 
 The methods we have described appear to be amenable to automation. 
 The necessary reasoning ability is the same as is needed for a program- 
 verification system; the program manipulation abilities are similar to what is 
 required of program-transformation systems. Of course, we do not expect these 
 methods alone to suffice for an automatic program-abstraction system to pro- 
 duce and apply program schemata. But we can envision the possibility of such 
 methods being embedded in a semi-automatic program-development environment in 
 which the system performs the more straightforward steps, and the human pro- 
 grammer guides the machine in the more creative ones. 
 
- 44 - 
 ACKNOWLEDGMENT 
 
 I sincerely thank Zohar Manna and Richard Waldinger for their gui- 
 dance in initiating this research. 
 
- 45 - 
 APPENDIX 
 
 Gerhart [1975] recommended the hand-compilation of a handbook of 
 program schemata. Such a collection of shemata, together with a library of 
 program transformations, could be used in an interactive program-development 
 system. In this appendix, we have culled fifteen representative schemata from 
 the programming literature. 
 
 We use the following nomenclature: 
 
 IN set of natural numbers 
 
 3R set of real numbers 
 
 Z set of integers 
 
 [u:v] set of integers between u and v 
 
 j,k,t input variable 
 
 x input variable or vector of variables 
 
 p,q predicate symbol 
 
 c,d,e,f,g,h function symbol 
 
 a,b constant symbol 
 
 z,r output variable 
 
 i,s,y,m program variable 
 
 u,v,w universally quantified variable (quantifier often omitted) 
 
 n existentially quantified variable 
 
 Each of the following schemata is followed by an output assertion giving its 
 
 abstract Input-output specification. They are preceded by an input assertion 
 
 containing the preconditions for correct application. The general format is 
 
- 46 - 
 
 S : begin 
 
 comment title (source) 
 
 purpose 
 assert type conditions, 
 
 correctness preconditions, 
 termination precondition 
 
 • • • 
 
 schema body 
 
 • • • 
 
 assert output specification 
 end. 
 
 The references are to sources that present an abstract schema; they are some- 
 what arbitrary, as the methods themselves are all well known. (The schemata 
 may differ in details from those given in the referenced sources.) 
 
 S i : begin 
 
 comment element-by-element (Gerhart [1975]) 
 
 achieve q for all integers between j and k 
 assert jeZ, kelR, bex, 
 
 ue[j:k]Avex 2) h(u,v)ex, 
 
 ue[j:k]Avex 3 q(h(u,v),u), 
 
 u,we[ j:k]AvexAu<wAq(v,u) Z) q(h(w,v),u) 
 (z,i) := (b,j) 
 loop assert (Vue[ j:i-l] )q(z ,u) , ie[ j:k+l] Vi=j>k+1, zex 
 
 until i>k 
 
 (z,i) := (h(i,z),i+l) 
 
 repeat 
 assert ( Vue[ j:k] )q(z ,u) , zex 
 end 
 
- 47 - 
 
 S 2 : begin 
 
 comment extremum (Dershowitz and Manna [1975]) 
 
 achieve q for all Integers between j and k 
 assert jeZ, kelR, 
 
 ue[j:k] D q(u,u), 
 
 u,v,we[ j:k]Au<vAq(w,u)A~lq(w,v) Z) q(v,u) 
 (z,i) := (j,j) 
 loop assert (Vue[ j:i] )q(z ,u) , z,ie[ j:k] Vi=j>k 
 
 until i>k-l 
 
 i := 1+1 
 
 if ~|q(z,i) then z := i fi 
 
 repeat 
 assert (Vue[ j:k] )q(z ,u) , ze[j:k]Vj>k 
 end 
 
 S3 : begin 
 
 comment linear-search (Dijkstra [1972]) 
 
 find least integer between j and k such that q holds 
 assert jeZ , kelR 
 
 z := j 
 
 loop assert ( Vue[ j:z-l] )~lq(u) , ze[ j:k+l] Vz=j>k+1 
 
 until z>kVq(z) 
 
 z := z+1 
 
 repeat 
 assert (3ne[ j:k] )q(n) Z) z=(min ne[ j :k] )q(n) , 
 
 z>j, z>kVq(z) 
 end 
 
- 48 - 
 
 Si*: begin 
 
 comment gradient-search (Misra [1978]) 
 
 search for local extremum 
 assert aex, 
 
 uex 2) t(u) Lx, 
 uex 3 q(u,u), 
 
 u,v,wexAq(w,u)A~lq(w,v) D q(v,u), 
 uLx 3 g(u)eu, 
 
 u,v,wexAq(u,w) 3 q(u,v)Vq(v,w), 
 (3nelN)|x|=n 
 comment |x| denotes the number of elements In the set x 
 z := a 
 loop (m, s) := (z,t(z)) 
 
 loop assert ( Vuet(m)-s)q(z ,u) , z,mex, sl_x 
 until s={} 
 y :■ g(s) 
 s := s-{y} 
 
 if ~" lq(z,y) then z :■ y fi 
 repeat 
 assert (Vuet(m))q(z,u) , zex 
 until z=m 
 repeat 
 assert ( Vuet(z) )q(z ,u) , zex 
 end 
 
- 49 - 
 
 S5 : begin 
 
 comment binary-search (Dershowitz and Manna [1975]) 
 
 approximate transition from q true to q false 
 assert a,b,telR, 
 
 q(a), ~lq(b), 
 
 q(u+t)At>v D q(u+v), 
 
 t>0 
 (z,y) := (a,b-a) 
 loop assert q(z), ~lq(z+y), a<z<z+y<bVa>b 
 
 until y<t 
 
 y :- y/2 
 
 if q(z+y) tben z := z+y fi 
 
 repeat 
 assert q(z), ~|q(z+t), a<z<b\/a>b 
 end 
 
- 50 - 
 
 Sg: begin proc sort(x[j:k] ) 
 
 comment sorting (Darlington [1978]) 
 
 sort array segment x[j:k] 
 assert x[ j:k]ea[ j:k] , 
 
 uea[u':w'] 2) f(u)ea[u" :w' ]*[u' :w'-l] , 
 uea[u' :v' ] Avea[v'+1: w'] Z) g(u,v)ea[u' :w'] , 
 uea[u':v']Avea[v'+l:w'] 2) bag(g(u,v))=bag(u) Ubag(v) , 
 uea[u':w']Af(u)=(w,v) 3 bag(u)=bag(w) , 
 
 uea[u' :w'] Af (u) = (w[u' :w'] ,v) Asorted(w[u' :v] )Asorted(w[v+l:w' ] ) 2) 
 sorted(g(w[u': v] ,w[v+l:w'])) 
 comment bag(u)=bag(v) means that for each occurrence 
 
 of an element in u there is an occurrence of the element in v; 
 sorted(w[u' :w'] ) = ( Vve[u' :w'-l] )w[v] <w[v+l] ; 
 a[u:v] is the set of arrays of elements of a 
 with indices in [u:v]; 
 
 x denotes the value of x upon procedure entry 
 if j<k then (x[j:k],m) :» f(x[j:k]) 
 sort(x[ j:m] ) 
 sort(x[m+l:k]) 
 
 x[j:k] := g(x[j:m],x[m+l:k]) fi 
 assert bag(x[ j:k] )=bag(x[ j:k] ), sorted(x[ j:k] ) 
 end 
 
- 51 - 
 
 S7: begin 
 
 comment associative-recursion (Darlington and Burstall [1976]) 
 
 compute f(x) 
 
 assert p(u) 3 f(u)=c(u), 
 
 h(u,c(u))=u, 
 
 ~[p(u) D f(u)=h(f(e(u)),d(u)), 
 h(u,h(v,w))=h(h(u,v),w), 
 (3nelN)p(e n (x)) 
 if p(x) 
 
 then z := c(x) 
 
 else (z,y) := (d(x),e(x)) 
 
 loop assert h(f (y) ,z)=f (x) 
 until p(y) 
 
 (z,y) := (h(d(y),z),e(y)) 
 repeat 
 z := h(c(y),z) 
 fi 
 assert z=f(x) 
 end 
 
 S 8 : begin 
 
 comment tall-recursion (Wirth [1976]) 
 
 compute f(x) 
 assert p(u) 2) f(u)=c(u), 
 
 ~|p(u) D f(u)=f(e(u)), 
 
 (3nelN)p(e n (x)) 
 y := x 
 loop assert f(y)=f(x) 
 
 until p(y) 
 
 y :■ e(y) 
 
 repeat 
 z :=» c(y) 
 assert z=f(x) 
 end 
 
- 52 - 
 
 S 9 : begin 
 
 content rlght-commutatlve-recurslon (Cooper [1966]) 
 assert p(u) 2) f(u)=a, 
 
 ~lp(u) D f(u)=h(f(e(u)),d(u)), 
 
 h(g(u,v),w)=g(h(u,w),v) , 
 
 h(a,u)=g(a,u), 
 
 (3ne]N)p(e n (x)) 
 (z,y) := (a,x) 
 loop assert u=(mln nelN)p(e (y)) 
 
 D f(x)-g(g(...g(g(2,d(y)),d(e(y) )),-.. ),d(e U_1 (y))) 
 
 until p(y) 
 
 (z,y) := (g(z,d(y)),e(y)) 
 
 repeat 
 assert z=f(x) 
 end 
 
 S 10 : begin 
 
 comment Invert Ible-recurslon (Cooper [1966]) 
 
 compute f(x) 
 assert f(a)=c(a), 
 
 u#a D f(u)-h(f(e(u)),u), 
 
 e(g(u))=u, 
 
 (3nelN)g (a)=x 
 (z,y) := (c(a),a) 
 loop assert z=f(y), (3nelN)(y=g (a) A(Vue[0:n-l] )g (a)*x) 
 
 until y=x 
 
 (z,y) := (h(z,g(y)),g(y)) 
 
 repeat 
 assert z=f(x) 
 end 
 
- 53 - 
 
 S i i : begin 
 
 comment stack-Introduction (Wossner, et al. [1978]) 
 
 compute recursive function f(x) using stack 
 
 assert p(u) 2) f( u ) =c ( u )> 
 
 ~lp(u) D f(u)=h(f(d(u)),u), 
 
 (3nelN)p(d n (x)) 
 
 comment s is the list (s ,s ,, ,,, ,s, ); 
 
 n n-1 1 
 
 head(s)=s ; tail(s)=(s ..•••,8 1 ); 
 n n-1 1 
 
 uo s =(u > s n ,-«-,s 1 ) 
 (y,s) := (x,()) 
 loop assert f (x)=h(- • -h(h(f (y) ,s n ) »3 j^) • • • .s^ 
 
 until p(y) 
 
 (y,s) := (d(y),yo s ) 
 
 repeat 
 z := c(y) 
 
 loop assert f(x)=h( ♦ • «h(h(z ,s ),s , )»««,s, ) 
 
 n n— l l 
 
 until s=() 
 
 (z,s) := (h(z,head(s)),tail(s)) 
 
 repeat 
 assert z=f(x) 
 end 
 
- 54 - 
 
 » 12 : begin 
 
 coament double-recursion (Knuth [1974]) 
 
 compute f(x) 
 assert p(u) Z) f(u)=c(u), 
 
 lp(u) ^ f(u)-h(f(e(u)),f(d(u))), 
 h(a,u)=u, 
 
 h(u,h(v,w))=h(h(u,v),w), 
 p(x)V(3nem)g n (x) = {}, 
 
 where g(u)={e(v) IveuAlp(v)} U{d(v) IveuAlp(v)} 
 
 come 
 
 nt s Is the 
 
 head(s)=s ; 
 n 
 
 list \ 
 tail(s 
 
 n n — 1 
 ')=(s n _ r -. 
 
 •,s 1 ); 
 
 -,8^5 
 
 
 
 (z,s) 
 
 uos=(u,s , • 
 n 
 
 :- (a,(x)) 
 
 ",8^ 
 
 
 
 
 
 loop 
 
 assert f(x) : 
 
 »h(z,h( 
 
 ;s 1 ,h(s 2> h( 
 
 •"' h( Vr 
 
 V 
 
 
 until s=() 
 
 
 
 
 
 
 
 (y,s) := (head(s), 
 
 tail(s)) 
 
 
 
 
 
 if p(y) 
 
 then 
 
 z := h(z,c 
 
 (y)) 
 
 
 
 
 
 else 
 
 s :■ e(y)c 
 
 d(y)os 
 
 fl 
 
 
 
 repeat 
 
 
 
 
 
 
 assert z=f(x) 
 
 
 
 
 
 
 end 
 
 
 
 
 
 
 
 )))) 
 
- 55 - 
 
 s 13 : begin proc back(t,x,z) 
 
 consent backtracking (Gerhart and Yelowitz [1976]) 
 
 collect all vectors beginning with x satisfying p 
 assert xea, 2Q, 
 
 uea 3 t( u ) La, 
 
 uLa 2) g(u)eu, 
 
 (3nelN)|t*({x})|=n 
 
 comment t*(u)=u|_ft (u) Ut~ 2 (u) U- • • , 
 
 where T(u) = U t(v); 
 veu 
 
 I* * 
 
 t (u) I denotes the number of elements in the set t (u); 
 
 z denotes the value of z upon procedure entry 
 if p(x) then z := zU{x} fi 
 y := t(x) 
 
 loop assert zU{uet (x)|p(u)} 
 =zU{uet*(y)|p(u)} 
 
 until y={ } 
 
 m := g(y) 
 
 y := y-{m} 
 
 back(t ,m,z) 
 
 repeat 
 assert z=z|_l{uet (x)|p(u)} 
 end 
 
- 56 - 
 
 <m'. begin 
 
 comment marking (Yelowitz and Duncan [1977]) 
 
 collect elements related by t to x 
 assert xCa, tIZa , 
 
 {n| (u,n)Ew} Cf(u,v,w) Cv, 
 
 uCa 2) g( u ) e u, 
 
 (3nelN)|t*(x)|-n 
 
 comment t (x) a x|Jt(x) Lit (x) [_]•••, 
 
 where t"(x)=»U {n|(u,n)et}; 
 uex 
 
 t (x) I denotes the number of elements in the set t (x) 
 (z,s,y) := (x,x,t) 
 loop assert sCzlZt (x) Cz Uy (s)Ca, yCt 
 
 until y-OVs-0 
 
 m := g(s) 
 
 s := sUf(m,z,y)-{m} 
 
 z := zU{u| (m,u)ey) 
 
 y :» y-{(u,v) |(m,v)ey} 
 
 repeat 
 assert z=t (x) 
 end 
 
- 57 - 
 
 S 15 : begin 
 
 comment additive-relation (Dershowitz and Manna [1981]) 
 
 achieve p(z) maintaining relation between r and z 
 assert g(u,v)=g(v,u) , 
 
 g(g(u,v),w)=g(u,g(v,w)), 
 
 h(h(u,v) ,w)=h(h(u,w) ,v) , 
 
 b(g(u,v),w)=g(h(u,w),h(v,w)), 
 
 (3nelN)p(d n (x)), where d(u)=g(u,h(f (u) ,a) ) 
 (z,r) := (x,t) 
 loop assert g(h(x,b) ,h(r,a) )=g(h(t,a) ,h(z ,b) ) 
 
 until p(z) 
 
 (z,r) := (g(z,h(f(z),a)),g(r,h(f(z),b))) 
 
 repeat 
 assert p(z), g(h(x,b) ,h(r,a) )=g(h(t,a) ,h(z,b) ) 
 end 
 
- 58 - 
 
 REFERENCES 
 
 [I] R.S. Boyer and J S. Moore [1980], Computational theorem proving , Academic 
 Press, New York. 
 
 [2] R. Brown [Oct. 1976], Reasoning by analogy , Working paper 132, Artificial 
 Intelligence Laboratory, MIT, Cambridge, MA. 
 
 [3] T.W. Chen and N.V. Findler [Dec. 1976], Toward analogical reasoning in 
 problem solving by computers , Technical report 115, Dept. of Computer 
 Science, State Univ. of New York, Buffalo, NY. 
 
 [4] D.C. Cooper [May 1966], The equivalence of certain computations , Computer 
 J. , vol. 9, no. 1, pp. 45-52. 
 
 [5] J. Darlington [Dec. 1978], A synthesis of several sorting algorithms , 
 Acta Informatica, vol. 11, no. 1, pp. 1-30. 
 
 [6] J. Darlington and R.M. Burstall [Mar. 1976], A system which automatically 
 improves programs , Acta Informatica, vol. 6, no. 1, pp. 41-60. 
 
 [7] N. Dershowitz [Nov. 1978], The evolution of programs , Ph.D. thesis, Dept. 
 of Applied Mathematics, Weizmann Inst, of Science, Rehovot, Israel; 
 available as Report R-80-1017, Dept. of Computer Science, Univ. of Illi- 
 nois, Urbana, IL. 
 
 [8] N. Dershowitz and Z. Manna [July 1975], On automating structured program- 
 ming , Proc. Colloq. IRIA on Proving and Improving Programs, Arc-et- 
 Senans, France, pp. 167-193. 
 
 [9] N. Dershowitz and Z. Manna [Nov. 1977], The evolution of programs : 
 Automatic program modification , IEEE Software Engineering, vol. SE-3, no. 
 6, pp. 377-385. 
 
 [10] N. Dershowitz and Z. Manna [Mar. 1981], Inference rules for program anno- 
 tation , IEEE Software Engineering, vol. SE-7, no. 2, pp. 207-222. 
 
 [II] P. Deussen [July 1979], One abstract parsing algorithm for all kinds of 
 parsers , Proc. Sixth EATCS Intl. Colloq. on Automata, Languages and Pro- 
 gramming, Graz, Austria, pp. 203-217. 
 
 [12] E.W. Dijkstra [1972], Notes on structured programming , in O.J. Dahl, E.W. 
 Dijkstra, and C.A.R. Hoare, "Structured Programming," Academic Press, 
 London . 
 
- 59 - 
 
 [13] E.W. Dijkstra [1976], A discipline of programming , Prentice-Hall, Engle- 
 wood Cliffs, NJ. 
 
 [14] A.G. Duncan and L. Yelowitz [July 1979], Studies in abstract / concrete 
 mappings in proving algorithm correctness , Proc Sixth EATCS Intl. Col- 
 loq. on Automata, Languages and Programming, Graz, Austria, pp. 218-229. 
 
 [15] S.L. Gerhart [Apr. 1975], Knowledge about programs : A model and case 
 study , Proc. Intl. Conf. on Reliable Software, Los Angeles, CA, pp. 88- 
 95. 
 
 [16] S.L. Gerhart and L. Yelowitz [Dec. 1976], Control structure abstractions 
 of the backtracking programming technique , IEEE Software Engineering, 
 vol. SE-2, no. 4, pp. 285-292. 
 
 [17] G. Huet and B. Lang [Dec. 1978], Proving and applying program transforma- 
 tions expressed with second-order patterns , Acta Informatica, vol. 11, 
 no. 1, pp. 31-55. 
 
 [18] R.E. Kling [Aug. 1971] , Reasoning by analogy with applications to heuris- 
 tic problem solving : A case study , Ph.D. thesis, Dept. of Computer Sci- 
 ence, Stanford Univ. , Stanford, CA. 
 
 [19] D.E. Knuth [Dec. 1974], Structured programming with goto statements , Com- 
 puting Surveys, vol. 6, no. 4, pp. 261-301. 
 
 [20] S. Lee, W.P. deRoever, and S.L. Gerhart [Jan. 1979], The evolution of 
 list-copying algorithms , Proc. Sixth ACM Symp. on Principles of Program- 
 ming Languages, San Antonio, TX, pp. 53-67. 
 
 [21] J. McDermott [Aug. 1979], Learning to use analogies , Proc. Sixth Intl. 
 Joint Conf. on Artificial Intelligence, Tokyo, Japan, pp. 568-576. 
 
 [22] Z. Manna and R.J. Waldinger [Summer 1975], Reasoning and knowledge in 
 program synthesis , Artificial Intelligence, vol. 6, no. 2, pp. 175-208. 
 
 [23] J. Misra [Sept. 1978], An approach to formal definitions and proofs of 
 programming principles , IEEE Software Engineering, vol. SE-4, no. 5, pp. 
 410-413. 
 
 [24] D.A. Plaisted [July 1980], Abstraction mappings in mechanical theorem 
 proving , Proc. Fifth Conf. on Automated Deduction, Les Arcs, France, pp. 
 264-280. 
 
 [25] T.A. Standish, D.C. Harriman, D.F. Kibler, and J.M. Neighbors [Jan. 
 1976] , The Irvine program transformation catalogue : A stock of ideas for 
 improving programs using source- to- source transformation s , Memo, Dept. of 
 Information and Computer Sciences, Univ. of California, Irvine, CA. 
 
- 60 - 
 
 [26] R.J. Sternberg [1977], Intelligence , Information processing , and analogi- 
 cal reasoning , Lawrence Erlbaum, Hillsdale, NJ. 
 
 [27] G.J. Sussman [1975], A computer model of skill acquisition , American 
 Elsevier, New York. 
 
 [28] J.W. Ulrich and R. Moll [Aug. 1977], Program synthesis by analogy , Proc 
 ACM Symp. on Artificial Intelligence and Programming Languages, Roches- 
 ter, NY, pp. 22-28. 
 
 [29] P.H. Winston [Dec. 1980], Learning and reasoning by analogy , CACM, vol. 
 23, no. 12, pp. 689-703. 
 
 [30] N. Wirth [1973], Systematic programming : An introduction , Prentice-Hall, 
 Englewood Cliffs, NJ. 
 
 [31] N. Wirth [1976], Algorithms + Data Structures - Programs , Prentice-Hall, 
 Englewood Cliffs, NJ. 
 
 [32] H. Wossner, P. Pepper, H. Partsch, and F.L. Bauer [Summer 1978], Special 
 transformation techniques , Proc Intl. Summer School on Program Construc- 
 tion, Marktoberdorf , West Germany, pp. 290-321. 
 
 [33] L. Yelowitz and A.G. Duncan [Aug. 1977], Abstractions , instantiations and 
 proofs of marking algorithms , Proc. ACM Symp. on Artificial Intelligence 
 and Programming Languages, Rochester, NY, pp. 13-21. 
 
BIBLIOGRAPHIC DATA 
 SHEET 
 
 1. Report No. 
 
 UIUCDCS-R-81-1011 
 
 2. 
 
 3. Recipient's Accession No. 
 
 4. Title and Subtitle 
 
 The Evolution of Programs: Program Abstraction 
 and Instantiation 
 
 5. Report Date 
 
 .Tun* 1Q«1 
 
 6. 
 
 7. Author(s) 
 
 Nachum Dershowitz 
 
 8. Performing Organization Rept. 
 No. 
 
 9. Performing Organization Name and Address 
 
 Digital Computer Laboratory 
 1304 W. Springfield 
 Urbana, IL 61801 
 
 10. Project/Task/Work Unit No. 
 
 11. Contract /Grant No. 
 
 MCS-79-04897 
 
 12. Sponsoring Organization Name and Address 
 
 National Science Foundation 
 Washington, D.C. 
 
 13. Type of Report & Period 
 Covered 
 
 14. 
 
 15. Supplementary Notes 
 
 16. Abstracts 
 
 Our goal is to develop techniques for abstracting a given set of programs into a pro- 
 gram schema and for instantiating a given schema to satisfy concrete specifications. 
 We suggest the formulation of analogies as a basic tool in program abstraction. An 
 analogy is first sought between the specifications of the given programs. The analogy 
 is then used as a basis for transforming the existing programs into an abstract schema 
 that represents the embedded technique, with the invariant assertions and correctness 
 proofs of the given programs helping to verify and complete the analogy. A given con- 
 crete specification of a new problem may then be compared with the abstract specifica- 
 tions of the schema to suggest an instantiation of the schema that yields a correct 
 program. A collection of program schemata is included in an appendix. 
 
 17. Key Words and Document 
 
 Analysis. 17o. Descriptors 
 
 
 
 abstraction, instantiation, program schemata, analo 
 
 gy, transformations, 
 
 program 
 
 manipulation, program development, program correctness 
 
 
 17b. Identifiers/Open-Ended Terms 
 
 
 17c. COSATI Field/Group 
 
 
 18. Availability Statement 
 
 19.. Security Class (This 
 Report) 
 
 UNCLASSIFIED 
 
 21. No. of Pages 
 
 63 
 
 20. Security Class (This 
 Page 
 
 UNCLASSIFIED 
 
 22. Price 
 
 r ORM NTIS-35 (10-70) 
 
 
 USCOMM-OC 40329-P7!