perspective, logic programs do have a notion of control ow, and the in terms of the central control ow the program embodies.

Transcription

1 Projections of Logic Programs Using Symbol Mappings Ashish Jain Department of Computer Engineering and Science Case Western Reserve University Cleveland, OH USA Abstract This work presents some formalization of our intuition that from an operational perspective, logic programs do have a notion of control ow, and the computational behavior of a \well-structured" logic program is best understood in terms of the central control ow the program embodies. Generalizing earlier work on program map theory, a concept of a projection of a logic program using a mapping for the literals appearing in the program clauses is introduced. If a well-structured program is considered an annotation of a basic control ow then projecting out the annotations will abstract the core structure. Projections are particularly useful for incremental program development methods. We demonstrate, using an incremental method for program construction from reusable components, that incremental addition of functionalities can be analyzed for a better design by manipulating the projection equations. We study the relationship between a program and its projections and characterize situations under which the functionality of a program can be orthogonally decomposed so that subsets of functionalities can be independently developed and understood. An example analysis for a better design using projections is presented. 1 Introduction What is a well-structured logic program? It is dicult to give a satisfactory answer to this question if only the declarative semantics are considered. From a declarative perspective, a logic program is a collection of formulae in rst-order logic representing knowledge about a problem with no inherent structure. However, when viewed operationally, logic programs do have a notion of control ow. Moreover, programmers nd it more intuitive to develop/explain programs using the operational behavior of the programs. For example, it is very common to hear sayings like \this program recurses down the following data-structure", \the search is made by a depth rst traversal of the graph", \the program computes the value bottom-up", etc. when the computational behavior of a program is explained.

2 We believe that a logic program should be termed well-structured if it has a well-dened and easy to understand control ow. It is our intuition that once the basic control ow of a logic program is identied, the functionality of the given program can be understood/explained in terms of the basic control ow. In this paper, we present \projections" of logic programs for abstracting out the basic control ow. Projections of logic programs are based on mappings for the literals which appear in the program clauses. Projections are particularly useful for incremental program development methods. Please note, we are not attempting to dene a mathematical structure concisely capturing the control ow of logic programs { a la the program dependence graphs for imperative programs, reduction graph for functional programs, etc. Rather, we take the meta-approach that the control ow of logic programs is best represented by logic programs. The key intuition behind this paper is that by projecting out certain \computational details" of a logic program, a simple program corresponding to the basic control ow of the given program can be abstracted out. Or stated from the perspective of a programming methodology, if we build \computational details" around a well-understood control ow then it is easy to explain the computational behavior of the nal program. To help esstablish context for the readers, here is some background into this research. A method for developing structured logic programs called \stepwise enhancement" has been presented in [9, 5, 7]. Stepwise enhancement incrementally builds a target program from simpler, well-understood, reusable programs by the application of standard programming techniques. A programming technique introduces additional functionality without altering the essential control ow of the program. A formalization of the intuitions behind stepwise enhancement is reported in [4]. The symbol mapping for dening a projection of a logic program is a generalization of the \program map" of [4]. The remainder of the paper is organized as follows: Section 2 formally de- nes a projection of a logic program. Section 3 establishes certain properties of these projections, and discusses how projections can help in decomposing the functionality of a program into orthogonal subsets. Section 4 presents an example of program analysis using projections. We present our conclusions in Section 5. 2 Projections of Logic Programs Projection of a logic program is dened relative to a mapping for the literals appearing in the program clauses. A projection of a logic program is obtained by mapping individual clauses. A mapping of a clause involves: a) deletion of certain literals appearing in the clause, and b) mapping of the remaining literals to literals with possibly lower arity. The mapping for the literals and the clauses is induced from a mapping for the predicate symbols. Predicate

3 symbol mapping is dened in Denition 2.3. We assume some familiarity with basic terminology of logic programming. [1] is a good reference for review of the terminology. Denition 2.1 Let V, F, and P respectively denote the denumerable sets of variables, function symbols, and predicate symbols for rst-order logic. Let > be a special predicate of arity 0 in P which we assume will not be used in any program text. Denition 2.2 Let C P denote the set of clauses of a logic program P. Given a logic program P, let V P, F P, and P P denote the variables, function symbols, and predicate symbols which explicitly appear in C P. Remarks: 1. For readability, though programs may use the same variable name for variables appearing in dierent clauses, they should be considered distinct variables. 2. Given a program P, V P, F P, and P P are proper subsets of V, F, and P respectively. 3. For brevity, we write terms with function symbols of arity 0 as `f' instead of `f()' and atomic formulae with predicate symbols of arity 0 as `p' instead of `p()'. Denition 2.3 Given a logic program, a mapping h : P P! P is a predicate symbol mapping if 8p 2 P P, arity(p) arity(h(p)). Since a literal l 0 may get mapped to a literal of lower arity, some of the arguments of l 0 should be deleted when mapping l 0. Besides deletion, the arguments may be re-shued. Mathematically, this is achieved by associating a projection sequence (Denition 2.4) with each predicate p in P P. Denition 2.4 A projection sequence from m to n, m n, is given by S m;n = x 1, x 2, : : :, x n where each x i is distinct and each x i 2 f1; 2; : : :; mg. Given a projection sequence S p m;n for predicate p where m is the arity of p and n is the arity of h(p), when a literal with p as predicate is mapped, the i th argument of the literal, 1 i m and i 62 S p m;n, gets projected out. The induced mapping for the literals and the clauses is more formally dened by the following denition: Denition 2.5 Given a logic program P, a predicate symbol mapping h p : P P! P, and the associated projection sequences with each predicate in P P, the induced mapping h for the literals and clauses of P is dened as follows: 1. for an atomic literal p(t 1 ; t 2 ; : : :; t m ) in P, if x 1 ; x 2 ; : : :; x n is the projection sequence of p then h(p(t 1 ; t 2 ; : : :; t m )) = h(p)(t x1 ; t x2 ; : : :; t xn )

4 2. for a negative literal :A, h(:a) = :h(a). 3. for any clause l 0 l 1 ; l 2 ; : : :; l n where n 0, h(l 0 l 1 ; l 2 ; : : :; l n ) = h(l 0 ) h(l 1 ); h(l 2 ); : : :; h(l n ). Remarks: We collectively refer to the predicate symbol mapping and the projection sequences by the induced mapping. Projection of a program with respect to a given induced mapping is dened as follows: Denition 2.6 Given an Q induced mapping h for P, the projection of P with respect to h, denoted h(p ), is the program corresponding to the set of clauses fdel(h(c))jc 2 C P and if l is the head of C then h(l) 6= >g where del(h(c)) is the clause obtained by deleting every > and :> from h(c). The deletion of certain literals during the mapping of a clause is achieved by the operation del. Simply stated, if a predicate p gets mapped to > under a given predicate symbol map then every literal in a clause of the program with p as the predicate gets deleted from the mapping. It should be noted that projections of logic programs are more general than the program maps for logic programs given in [4]. In particular, Q h(p ) = Q does not imply that h is a program map from P to Q. For h to be a program map from P to Q, each predicate and function symbol in Q should have a unique inverse image under h in P. Here we have implicitly assumed a 1-1 mapping for the function symbols; thus, each function symbol in Q has a unique inverse in P. However, the same is not true for the predicate symbols. The predicate symbol mapping is strictly more general that the bijective mapping of the program maps. On the other hand, if h is a program map from P to Q then Q h(p ) = Q albeit with a slight re-interpretation of the mapping of the function symbols. Sine a program Q map includes a bijective mapping for the function symbols, the equation h (P ) = Q holds modulo consistent renaming of the function symbols. Generalizing 1-1 mapping of predicate symbols under the program maps to many-1 mapping under the projections has a tradeo. Projections are stronger, as will be discussed in the following section, as they allow a broader class of programming techniques or modication operations on the reusable program units. However, the generalized modication operations do not necessarily preserve the computations of the programs to which they are applied, a result true for the application of programming techniques of program maps ([4]). So while the broader class of operations aids in program development and maintenance, correctness proofs of nal programs cannot be leveraged as easily as under the program maps. One can take successive projections of a complicated program till (s)he has identied the program corresponding to the \core structure". We will

5 discuss this approach in greater details in the next two sections. As an example of how projection \strips" a program of some of its functionality to get to Q the core, consider programs and the mapping h given in Figures 3 and 4. h(p 1 ) = P 0. We conclude the section with the following denition which denes composition of successive projections. Denition 2.7 Given Q h 1 (P ) = Q and Q h 2 (Q) = S, the composition of h 1 and h 2, denoted, h 1 h 2, is dened as follows: 1. 8p, p 2 P P, if h 1 (p) 6= > then dene h p (p) = h 2 (h 1 (p)) else dene h p (p) = >. 2. 8p, p 2 P P, if h 1 (p) = > then dene the projection sequence for p to be else dene the projection sequence as x y1 ; x y2 ; : : :; x ym where x 1 ; x 2 ; : : :; x n is the projection sequence of p under the mapping h 1, and y 1 ; y 2 ; : : :; y m is the projection sequence of h 1 (p) under the mapping h 2. The predicate symbol mapping h p and the new projection sequences dened above are the basis for the induced mapping h 1 h 2. The following property of the successive projections follows from Denition 2.7. Property 1 Given Q h 1 (P ) = Q and Q h 2 (Q) = S then Q h 1 h 2 (P ) = S. 3 Incremental Construction and Program Projections As stated, the aim for projecting logic programs is to abstract the core control structure. If a program achieves certain functionality, abstractly denoted by ( x 1 ; x 2 ; : : :; x n ), and if we could identify syntactic constructs contributing to a particular subset of the functionality then we can delete those constructs to \strip" the program of that functionality. If we do it successively then we would be left with a core program with a simple and easy to understand control ow. Of course, if a program has no notion of a structure; that is, program is so written that none of the functionality can be viewed independently then we cannot do any better than explaining the program in its entirety. Assuming that the program has a structure, the question is, how useful are our projections in associating constructs with functionality? Obtaining a projection of a logic program involves identication of literals and argument positions which should be projected out. For arbitrary programs, the best we can do is use heuristics for projections. For example, if the mode of usage of a program is known then projecting non-ground arguments of the main predicate and removing goals which manipulate these

6 arguments may help. If the program was developed incrementally, adding a subset of functionality at a time, then the design can be analyzed in terms of the incremental projections. Such post-development analysis of the design in terms of incremental projection equations can lead to a natural decomposition of the nal program's functionality where subsets of functionality which do not depend on each other can be independently developed. In other words, incremental construction adds functionality in a \layered" manner, and using projections we can strip a layer, rearrange layers for a better design, or decompose the program into \orthogonal" layers. This is the main advantage of projections and will be the focus for the remainder of this section. The stepwise enhancement method proposed in [5, 9] develops programs incrementally. Program development using stepwise enhancement starts with a small, well-understood skeleton program and successively applies standard programming techniques to incrementally add functionality. Programming techniques modify programs in a well-dened manner. The theory of program maps given in [4] captures the incremental changes made to a program by techniques. That is, if (P ) = Q Q for some technique then there exists a program map h from P to Q, and h (P ) = Q modulo consistent function symbol renaming. Since projections are strictly more general than program maps they capture a broader class of modication operations. Solving a problem in essence solves a class of related problems. Very often, a solution is obtained by modifying the (known) solution of a related problem. For example, consider modication of a DCG to build the parse tree. The typical steps performed to modify a logic program to solve a related problem can be identied as: 1) renaming a predicate with a new predicate of possibly higher arity in which case additional arguments would be provided, 2) consistent rearrangement of the arguments, 3) introduction of new goals with new predicate symbols manipulating the newly added arguments, and 4) introduction of new clauses dening the predicates of the new goals added. Predicate symbol mappings and projection sequences can succinctly capture the modications done. Consider for example an incremental construction starting from an initial program P 0 implementing functionality ( x 0 ) and successively moving towards the nal program P n implementing functionality ( x 0 ; x 1 ; : : :; x n ) using generic modication operations as discussed above. A graph which we will call program development graph capturing the program development history, and incremental addition Q of functionality for such a design is given in Figure 1. In Figure 1, h i (P i ) = P i?1, 1 i n. Such a design, however, has an obvious aw with respect to future modi- cations. Due to the degenerate linear structure, if the program needs modication at a later date, due to a ripple eect a lot of changes may be needed in order to incorporate the desired modications. For stepwise enhancement, this shortcoming in linear design was pointed out by Lakhotia in [5]. He also suggested that for orthogonal functionalities, a program should be enhanced

7 P 0 h 1? P 1 h 2? : : :P n?1 h n? P n (x 0 ) h 1? (x 0 ; x 1 ) h 2? : : : (x 0 ; x 1 ; : : :; x n?1 ) hn? (x 0 ; x 1 ; : : :; x n ) Figure 1: Incremental construction using modication operations independently in parallel, and later automatically merged using a composition operation. However, the development still required clairvoyance from the user for decomposing the required functionality into orthogonal subsets. Using projection equations, one can elegantly decompose a design to avoid a linear degenerate structure. Given a linear structure of Figure 1, the key is deciding if the computational layer added from P k?1 to P k manipulates (syntactically) any variable or predicate symbol which was added for the rst time by program P j for some j < k. This can be syntactically checked using the criteria given by Denition 3.2. For the discussion to follow, h 0 is implicit. Assume 8p 2 P 0, h 0 (p) = >. Denition 3.1 Let h i;j denote the composition h i h i?1 : : : h j. h Denition 3.2 Given a linear structure 1 h P 0? n P 1 : : :? P n, the modications done going from P k?1 to P k are orthogonal to the context added for the rst time by P j, 0 j < k n, i: 1. None of the arguments which get projected out from the literals under the mapping h k contains variables added for the rst time by P j (V Pj n V Pj?1 is the set of variables added by P j for the rst time). Note that if a literal l gets deleted in the projection then it should be assumed that all the arguments of l get projected out. 2. P k should not enhance any literal added for the rst time by P j ; that is, 8p 2 P Pk, if h j (h k;j+1 (p)) = > then arity(p) = arity(h k;j+1 (p)). Note that h k;j+1 (p) 2 P Pj. The decomposition of the functionality proceeds as follows: Find maximal j such that the n th layer added is not orthogonal to the context added for the rst time by P j. This means that the n th modication can be done directly to P j. It also implies that (x 0 ; : : : ; x j ) h n 0? (x 0 ; : : : ; x j ; x n ) can be done independent of the development (x 0 ; : : : ; x j ) hj+1? (x 0 : : : x j ; x j+1 ) : : : hn?1? (x 0 ; : : : ; x j ; : : :; x n?1). The advantage of such a decomposition is that the program behavior (including correctness) of the nal program with respect to x n can now be done relative to P j instead of P n?1. A key thing to note

8 P n?1..= }... P j = P 0 P 1 P j } = P n 0 P n Figure 2: Program development graph after rst decomposition is that the modied projection h n 0 together with the program text code corresponding to the functionality (x 0 ; : : :; x j ; x n ) can be automatically obtained by a restructuring tool since all the information needed to strip a computational layer and adding it to another program is available. Such a maintenance tool is in the scope of future work. Let P n 0 denote the program corresponding to the functionality (x 0 ; : : : ; x j ; x n ). The modied program development graph is given in Figure 2. The decomposition process continues with the new design of Figure 2 by h recursively decomposing the program development subgraphs 1 P 0? P 1 : : : h j h j+1? P j and P j? Pj+1 : : : h n?1? P n?1. Another key aspect of such a restructuring is that merging can be done automatically. For example, in Figure 2, P n?1 can be automatically merged with P n 0. In case of stepwise enhancement, this operation is called composition and an algorithm for composition appears in [9]. However, since the projections here are more general than program maps, the composition operation of stepwise enhancement should be generalized. Since composition is not in the scope of this work, we beg the reader's indulgence as we present only an overview of the merge operation. The generalized composition algorithm is in the scope of future work. Given Q h 1 (P ) = Q h 2 (Q) = S, functionalities of P and Q can be merged automatically with respect to S. P and Q are merged with respect to S by merging all the corresponding clauses of P and Q with respect to S (two syntactic entities correspond if they have the same projection under their respective mappings) followed by, addition of all the non-corresponding clauses of P and Q. Two corresponding clauses c p and c q with respect to c s, are merged by merging all the corresponding literals of c p and c q, followed by, addition of all the non-corresponding literals of c p and c q. The merging of corresponding literals l p and l q with respect to l s is obtained by adding at the end of l s all the non-corresponding arguments of l p, followed by all the non-corresponding arguments of l q.

9 P 0 :: traverse(tree(andor,node,children)) traverse list(children). traverse list([ ]). traverse list([xjxs]) traverse(x), traverse list(xs). Figure 3: The basic control ow 4 Example We present an example program to demonstrate how decomposition works. The following problem was given as an exercise for a LISP programming course. Given a representation for AND-OR trees, compute all the nodes which are successful nodes, and nd the total number of nodes in a given AND-OR tree. Consider all AND leaf-nodes successful and all OR leaf-nodes failed. A preliminary look at the problem statement reects that any program implementing the required functionality has to do a complete traversal of the given AND-OR tree. We propose program P 0 given in Figure 3 as the starting point. We incrementally build the functionality. For the rst step, we modify program P 0 to compute labels for each node. A node is labeled `true' or `false' based on the conventions of an AND-OR tree. Program P 1 is given in Figure 4. The mapping h 1 which induces a projection from P 1 to P 0 is also given in the same gure. Using the control ow of P 1, one can collect the successful nodes based on the labels of the nodes. We modify P 1 to obtain a program P 2 which collects the successful nodes of the given tree. P 2 with the associated projection is given in Figure 5. Finally, the constructs for counting the number of nodes in the given AND-OR tree are added to P 2. Program P 3 and the associated projection is given in Figure 6. As expected, if P 3 is decomposed then one would notice that counting can be done independent of P 1 and P 2 since the maximum j for which modication done in going from P 2 to P 3 is orthogonal with respect to P j is 0. Further, P 2 is not orthogonal with respect to P 1 since P 2 adds the goal parent inclusion(label,,, ) which refers to a variable which was added for the rst time by P 1. Thus, we conclude that P 0 should be directly enhanced

10 P 1 :: label(tree(andor,node,children),label) initial label(andor,initlabel), label list(children,andor,initlabel,label). label list([ ],AndOr,Label,Label). label list([xjxs],andor,labelin,labelout) label(x,label), and or(andor,label,labelin,labeltemp), label list(xs,andor,labeltemp,labelout). initial label(or,false). and or(and,true,true,true). and or(and,false,true,false). and or(or,true,true,true). and or(or,false,true,true). initial label(and,true). and or(and,true,false,false). and or(and,false,false,false). and or(or,true,false,true). and or(or,false,false,false). h p (label) = traverse, h p (label list) = tarverse list, h p (initial label) = >, h p (and or) = > label list initial label and or 2;1 = 1, S4;1 = 1, and S2;0 = S4;0 =. S label Figure 4: The rst incremental modication and the associated projection to get the functionality of counting the number of nodes in the AND-OR tree. P 0 should be independently enhanced to P 1, and P 1 should then be enhanced to P 2. Both the segments of the enhancement should then be composed. The program development graph for our example is given in Figure 7. Note that program P 0 3 corresponds to the addition of Q syntactic entities which would get projected out during the projection h 3 h 2 (P 3 ) directly to P 0. A restructuring tool can automatically generate P 0 3 as all the required restructuring information is present. 5 Conclusions We presented projections for logic programs for abstracting the core structure of well-structured logic programs. We outlined a method for incremental construction of logic programs using generic modication operations which added functionality in a layered manner. The modications operations are strictly more general than programming techniques of stepwise enhancement ([5, 9, 7]). Incremental construction for software development has been advocated by others as well ([10, 3, 2]). However, in order to reduce the \ripple

11 P 2 :: nodes(tree(andor,node,children),label,nodes) initial label(andor,initlabel), nodes list(children,andor,initlabel,label,[ ],ChildNodes), parent inclusion(label,node,childnodes,nodes). nodes list([ ],AndOr,Label,Label,Nodes,Nodes). nodes list([xjxs],andor,labelin,labelout,nodesin,nodesout) nodes(x,label,nodes), append(nodes,nodesin,nodestemp), and or(andor,label,labelin,labeltemp), nodes list(xs,andor,labeltemp,labelout,nodestemp,nodesout). initial label(or,false). and or(and,true,true,true). and or(and,false,true,false). and or(or,true,true,true). and or(or,false,true,true). initial label(and,true). and or(and,true,false,false). and or(and,false,false,false). and or(or,true,false,true). and or(or,false,false,false). parent inclusion(true,node,nodes,[nodejnodes]). parent inclusion(false,node,nodes,nodes). h p (nodes) = label, h p (nodes list) = label list, h p (initial label) = initial label, h p (and or) = and or, h p (parent inclusion) = h p (append) = > S nodes nodes list initial label 3;2 = 1; 2, S6;4 = 1; 2; 3; 4, S2;2 = 1; 2, and or parent inclusion S3;3 = 1; 2; 3, and S4;0 = S append 3;0 =. Figure 5: The second incremental modication and the associated projection eect" in a linear development structure, we used projections for identifying independent enhancements (orthogonal layers) of logic programs. We believe, orthogonally decomposing a program helps in a better understanding of the programming process and is a suitable basis for writing well-structured programs. Also, there is substantial scope for automating the software development using a high-level editing tool similar to the ones proposed in [6] and [8]. As pointed out earlier, besides development, almost every aspect of the restructuring can be automated. We propose to develop an integrated environment, both for development and restructuring, in the near future.

12 P 3 :: count nodes(tree(andor,node,children),label,nodes,count) initial label(andor,initlabel), count nodes list(children,andor,initlabel,label,[ ],ChildNodes,1,Count), parent inclusion(label,node,childnodes,nodes). count nodes list([ ],AndOr,Label,Label,Nodes,Nodes,Count,Count). count nodes list([xjxs],andor,labelin,labelout,nodesin,nodesout, CountIn,CountOut) count nodes(x,label,nodes,count), append(nodes,nodesin,nodestemp), plus(countin,count,counttemp), and or(andor,label,labelin,labeltemp), count nodes list(xs,andor,labeltemp,labelout,nodestemp,nodesout, CountTemp,CountOut). initial label(or,false). and or(and,true,true,true). and or(and,false,true,false). and or(or,true,true,true). and or(or,false,true,true). initial label(and,true). and or(and,true,false,false). and or(and,false,false,false). and or(or,true,false,true). and or(or,false,false,false). parent inclusion(true,node,nodes,[nodejnodes]). parent inclusion(false,node,nodes,nodes). h p (count nodes) = nodes, h p (count nodes list) = nodes list, h p (initial label) = initial label, h p (and or) = and or, h p (parent inclusion) = parent inclusion, h p (append) = append, h p (plus) = > count nodes S count nodes list initial label 2;2 = 3;3 = 4;3 = 1; 2; 3, S8;6 = 1; 2; 3; 4; 5; 6, S and or parent inclusion 1; 2, S3;3 = 1; 2; 3, S4;4 = 1; 2; 3; 4, S append 1; 2; 3, and S plus 3;0 =. Figure 6: The nal program and the associated projection

13 P 1 + } P 2 } P 0 P 3 + P 0 3 Figure 7: The program development graph of P 3 Acknowledgments I would like to acknowledge Leon Sterling and Marc Kirschenbaum for providing me with valuable insights into this work. I would also like to thank the reviewers for their constructive comments. This research was supported by NSF Grant No. CCR References [1] Krzysztof R. Apt. Introduction to logic programming. In J. van Leeuwen, editor, Handbook of Theoretical Computer Science{Vol. B, chapter 10, pages 495{571. The MIT Press/Elsevier, [2] R.G. Dromey. Systematic program development. IEEE Transactions on Software Engineering, 14(1):12{29, January [3] M.S. Feather. Constructing specications by combining parallel elaborations. IEEE Transactions on Software Engineering, 15(2):198{208, February [4] Marc Kirschenbaum, Leon Sterling, and Ashish Jain. Relating logic program via program maps. Annals of Mathematics and Articial Intelligence, 8(III-IV):229{246, [5] Arun Lakhotia. A Workbench for Developing Logic Programs By Stepwise Enhancement. PhD thesis, Case Western Reserver University, Department of Computer Engineering and Science, [6] C. Rich and R.C. Waters. The Programmer's Apprentice. Addison- Wesley, 1990.

14 [7] Leon Sterling and Marc Kirschenbaum. Applying techniques to skeletons. In J.M.J. Jacquet, editor, Constructing Logic Programs, chapter 6, pages 127{140. John Wiley, [8] Leon Sterling and Chok Sitt Sen. A tool to support stepwise enhancement in prolog. In ILPS '93 Post Conference Workshop on Methodologies for Composing Logic Programs, Vancouver, October [9] Leon Sterling and Ehud Shapiro. The Art of Prolog. The MIT Press, 2 nd edition, [10] N. Wirth. Program development using stepwise enhancement. Communications of the ACM, 14(4):221{227, 1971.