Teaching prolog techniques

0360- I3 I5/93 $6.00 + 0.00 Copyright 0 1993 Pergamon Press Ltd Computers E&c. Vol. 20. No. I, pp. 111-117, 1993 Printed in Great Britain. All rights reserved TEACHING PROLOG PAUL Department of Artificial Intelligence, University TECHNIQUES BRNA of Edinburgh, 80 South Bridge, Edinburgh, Scotland Abstract-Learning Prolog or any other programming language requires the student to relate the behaviour of code to its structure. We outline work on the development of an approach to helping students learn Prolog via Prolog programming techniques. After introducing the notion of programming techniques we sketch the reasons why they are of potential interest in teaching students to program. We describe some preliminary work on the development of a Prolog Techniques editor. Although this tool has not yet been used with students we anticipate a number of problems in learning to use it. 1. INTRODUCTION Over the last 10 years, Prolog has become a popular programming language. It has been used in a wide variety of educational settings-from primary schools in England to postgraduate work in University departments around the world. The reasons for teaching Prolog are diverse-see[l] for a brief analysis. Generally, the methods used for teaching Prolog have been much the same as for teaching other programming languages. The context addressed in this paper is teaching Prolog to degree level students of Artificial Intelligence. In this context, Prolog is a means to an end (the reasons for using Prolog rather than some other language have been outlined in[2]). We have some experience in teaching Prolog but find that novices have considerable difficulties in getting Prolog to do something useful. The problem focussed upon is therefore how to help students write programs. There is a need to provide more support for how to go from some wanted program behaviour (often, an informal program specification) to the code that has desired properties. In order to consider this problem in greater depth, we are interested in exploring a novel way of teaching Prolog based on the notion of Prolog programming techniques. 2. LEARNING TO PROGRAM Novices, whether familiar or unfamiliar with other programming languages, have difficulty in making Prolog ‘do something’. They find it extremely hard, for example, to understand how the declarative reading of append/3 (see below) achieves the intended, or indeed any, result. Constructing the program from the specification would therefore be almost impossible. append([ lJJ4. append([H 1Ll],LZ,[H ( L3]):append(Ll,L2,L3). There are many reasons why novices have such difficulties. One problem is how to integrate a declarative understanding of a program with some procedural understanding, e.g.[3]. Another problem is that Prolog code provides few clues as to how the execution of Prolog is determinedthis is related to Green’s notion of role expressiveness[4]. A further problem lies in the difficulty novices have with writing and understanding recursive programs (in any language), e.g.[5]. Experts, on the other hand, are capable of choosing the most convenient way of viewing a Prolog program. They may choose between a variety of different semantics for Prolog according to their needs (not just the simple declarative and procedural descriptions found in introductory texts). They may also switch between levels of description-moving from a description of the code to discuss program behaviour in terms of Prolog implementation details. They may move from a theoretical analysis of the underlying computational complexity to a discussion as to how they can gain extra coding efficiency by switching arguments around (appealing, for instance, to some low level abstract machine). They can choose between different methods for coding a solution and 111 112 PAUL BRNA zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA justify their choice. They can recognise common structures in their code and see how to make use of these in a variety of ways. The basic task, however, is not to describe the ways in which the novice falls short of expert knowledge and behaviour, but to help the novice to change. If some notion of technique is part of the equipment of the expert then we might hope that by teaching about techniques explicitly the novice might be given a better chance of emulating the expert. This process can be seen, in part, as forming more reliable, explicit programming plans. 3. PROLOG It is a common programming PROGRAMMING TECHNIQUES that many Prolog programs feature similar patterns. The term zyxwvutsrqpon Prolog to capture the computational motivation for these patterns. use of an accumulator pair (two boxed arguments) to build recursive data for reverse/2 which is a relation between two lists such that one is the reverse use of an accumulator argument (Act in the second clause of reverse/3) and in the second clause of reverse/3) in: observation techniques is intended An example is the structures in the code of the other. See the result argument (Res reverse(List,ReversedList):reverse(List,[ ],ReversedList). reverse( [ 1,jAcc,j reverse([H ). IT], II):reverse(T, I[HIAcc], ). to build the output list and the use of the result argument Res to return it as output. It is important to realize that a Prolog programming technique is not an algorithm. An algorithm can be thought of as a language-independent procedure which meets some specification, e.g. concatenate two lists together. A technique is language dependent, i.e. we are considering Prolog techniques. A technique is chosen according to the requirements of the algorithm selected and hence only indirectly upon the specification. A technique might, for example, be used both to sort a list and to find the maximum of two numbers, Furthermore, a technique might apply to only part of a complete procedure, and several techniques might need to be combined together to implement a procedure. A technique might also be confused with the notion of a clicht[6,7]. A cliche is less restrictive than either an algorithm or technique. The notion seems to include both algorithms for specific tasks, e.g. sorting a list, and language independent techniques. There is no attempt to be parsimonious: in the Programmer’s Apprentice users can build a large and redundant library of cliches embodying whole or part algorithms and generalized to the extent they specify. In contrast, we intend our techniques to be a parsimonious set and to be maximally generalized. We want a small set of techniques from which Prolog programs can be generated by combination and specialization. We expect to discover something of the order of 100 commonly occurring techniques. This parsimony solves some problems of retrieval caused by the large number of cliches. Figure 1 illustrates the point about the distinction between an algorithm and a technique. Algorithms are selected according to the nature of the specifications. Techniques are selected according to the algorithms chosen. Techniques are therefore only indirectly related to the specification. 4. PROGRAMMING TECHNIQUES VS PROGRAMMING PLANS Related work includes that by Soloway and his colleagues at Yale who made use of the notion of programming plans. Their main goal was an attempt to gain leverage on the problem of 113 zyxwvut Prolog techniques Specification c Program Algorithm + Techniques Fig. I. Techniquesand softwareproduction. recognizing and describing semantic errors in the code produced by novice Pascal programmers [8,9]. Spohrer has taken this further by seeking to model how students might use plans to build programs [ lo]. We regard Prolog programming techniques as related closely to that of the programming plans of Soloway et al.-but not identical. By the definition outlined here, a programming technique can be seen as a special form of programming plan. Various workers have looked for evidence that novices and experts possess programming plans, e.g. [1 1,121. Rist has provided some further empirical evidence for the existence of such programming plans [13]. However, Gilmore has pointed out that having a programming plan is not much use unless there is some knowledge present about when to apply the plan[l4]. No very strong claims are being made in this paper about the psychological reality of Prolog programming techniques. Insofar as these techniques are also (fragments of) programming plans then that there is at least some possibility of psychological reality worth some further exploration. 5. POTENTIAL ADVANTAGES AND DISADVANTAGES One way of helping students learn to program is to teach a ‘notional machine’ for Prolog[lS]. This, however, only goes part of the way in assisting in the transition from novice to expert. Another approach is to teach Prolog schemata. That is, the emphasis is primarily on teaching the commonly occurring patterns found in Prolog programs. This is still problematic since it remains difficult to make the connection between the way in which a schema is composed out of basic Prolog structures and the way in which the schema’s behaviour is determined by the behaviour of the schema’s constituent parts. This problem applies both for writing code in terms of schemata and for understanding code in terms of schemata. A major potential advantage of teaching about Prolog programming techniques lies in the way it helps to split up the problem of constructing programs. We can separate out the choice of algorithm from the choice of programming techniques. This could help to cut down the cognitive load. We also propose to divide the application of techniques into two further areas: the selection of what is essentially a control flow schema; and then the modification of this schema in a limited number of ways to establish the correct dataflow. Although there is likely to be some interplay between working on the control flow and working on the data flow, there should be some benefits in helping students think in these terms. We are aware that there are some difficult problems that need to be confronted both in technical and educational terms. If Prolog programming techniques are to have a part to play in the teaching of Prolog then there are a number of further questions that need to be consideredincluding: An Extra Burden: if students have trouble learning Prolog then will they not find the additional burden of learning Prolog programming techniques to be excessive? 114 PAUL BRNA Making the Connection: if students already have problems making the connection between the declarative reading and the procedural reading of their programs then exactly how will Prolog programming techniques help them with this problem? Where Do Techniques Fit: if techniques are going to be introduced into the teaching of Prolog in a more thorough way then where does this fit into the basic curriculum for teaching Prolog? How Abstract: top level experts may make use of a very abstract representation for techniques. For example, they may appear to abstract mathematical theory and may make use of complex and highly abstract operations to manipulate techniques in suitable ways. Should highly abstract descriptions of techniques be chosen? Novices learn to code simple programming problems. In doing so, they may pick up either good or sub-optimal practice-although what is good practice can quite reasonably be regarded as dependent on the stage at which the student is at. This process can be seen as learning to chunk as. for example, found in Laird’s notion of chunking [16]. From this perspective, the student is learning a syntactic pattern observed in the code, the salient features in the context in which the chunk is found useful, and the general effect of using the chunk. There are two distinct paths to be taken: to use explicitly taught techniques in a normative way in order to avoid basic errors; or to seek some way of illuminating the various issues. This suggests that normal methods of teaching need to be supplemented with the help of some software tool. If, however, the tool enforces a normative view of techniques then we are almost back where we started as Prolog + Techniques can be seen as (roughly) an enhanced Prolog. The greater need is to help the student: recognize successful and unsuccessful patterns; generalize and specialize patterns; learn both when and when not to use them; distinguish between algorithm and technique; and also learn to distinguish clearly between control flow and data flow. This approach might help the student to make the right connections between the structure of code chunks (embodying Prolog techniques) and the function of the chunk. Without such help, students might well retain a kind of “magic” view of adapting code structure to attain their ends without a clear understanding of how these ends are really achieved, as per Kahney[5]. Given that the extra time needed to learn and practice techniques is worthwhile then a decision is needed on both the techniques on which to focus and the instructional sequence which should be followed. This sequence has to be determined in part by the student’s own experience with programming and Prolog, and any relevant disciplines such as mathematics. Once the set of interesting techniques has been chosen, some example problems have also to be chosen which can be used as the basis for extracting the description of the technique. This would seem to be pedagogically more desirable than the introduction of the technique followed by exemplars. The determination of the sequence is by no means trivial-even if there are only 40 or so fundamental techniques-as there has to be some allowance for the composition of two or more techniques and various legitimate generalizations and specializations. The choices may tend towards: l l l l Specialized versions of techniques over more general versions, Simplified methods of technique composition over more sophisticated methods, Reducing the importance of efficiency issues in the first instance, Making use of procedural versions of techniques over declarative versions, where relevant. There is a preference here to make use of procedural intuitions in the learning path. Although top-flight experts emphasize that it is possible to gain great computational and conceptual efficiency from adopting a declarative description of techniques, where possible, it would be surprising if novices found this to be an easy step. 6. PRELIMINARY WORK Some preliminary attempt has been made to introduce the formal descriptions of techniques into Prolog courses at the Department of Artificial Intelligence, Edinburgh University. At this stage a number of issues have been identified. Prolog techniques 115 It has been found that students who were given the chance to practice the application of techniques in small classes responded with interest. Typically, at the start of such a class they would have heard techniques described explicitly but would not have practiced them. Again, typically, they would have great difficulty applying their knowledge to solve simple programming tasks. In the first stages of writing simple programs students find it difficult to choose the appropriate technique. Students exposed to teaching about techniques also show signs that their buggy solutions to programming tasks can sometimes be interpreted in terms of the faulty composition of explicitly taught techniques. Although these observations are informal, they are suggestive of the difficulties to be found in incorporating techniques into a Prolog programming course without some form of software support. Moving on to the provision of the necessary software support, two prototype editors have been built recently in the Department. The first is essentially a structure editor that knows about various primitive recursion schemata [17]. The editor has been specially designed to enforce the requirement that any program produced using these schemata must terminate. For a number of reasons, however, it is not suitable for novices in its present state: the interface requires the user to perform many repetitive actions which could be avoided using modern interface techniques; the primitive commands are typically at too low a level (this point is a partial explanation of the previous one); and the schemata themselves are quite hard to comprehend. Despite these problems, the recursion editor demonstrates that it is feasible to build an editor to make use of knowledge about Prolog programming techniques. The second prototype editor has been built by Robertson [ 181.This system is based on ideas from Kirschenbaum et al.[19]. Robertson’s prototype system provided a testbed for the exploration of the basic issues in helping novice programmers learn through and about techniques. The system is provided with a set of predicate descriptions. Each description provides: the name of the predicate; a list of arguments along with their types; and a list of test goals for which the predicate must succeed. The prototype allows the student to introdude techniques one after the other. The student is provided with assistance in making various choices-which predicate to define, which control structure (skeleton) to use, which modifications to use. If a dead end is reached or the student decides that he/she has made a mistake then the system can back up in a fairly simple manner to allow other paths to be explored. The prototype has given us the foundation to develop a system which meets some of the educational requirements outlined above. However, the approach to teaching Prolog embodied in this prototype is over simple: it is hard for a novice to deduce why a particular skeleton is the correct one to choose; it is hard to unwind the consequences of a decision made much earlier (this is a general problem for any Prolog techniques editor); and it is not always possible to understand why some incorrect decision would lead to incorrect program behaviour. 7. ILLUSTRATING THE PROBLEMS: SYNTHESIZING append/3 Perhaps it is now worth returning to consider how we might build a simple Prolog program- append/3. The following description very loosely follows the use of the recursive techniques editor described in [ 171 and is intended mainly to illustrate the nature of the problem facing the student. Building append/3 can be seen as composed of two kinds of decision: picking a control structure and enhancing it in various ways. Loosely, the control structure for append/3 can be described as zyxwvut process all elements in list. The schematic form might be: process_alZ([ I). process_all([H (TJ):- process-one(H), process- all(T). where process- one/l takes H as input. So the first problem faced by the student is to choose a schema with the desired control flow. It would help if the student could be given a tool to visualize the control flow in some way. 116 PAUL BRNA Note that, in the above, both zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFED process- all and process- one are second order variables awaiting instantiation to the names of predicates. Now this basic schema can be enhanced in two ways. First, a result argument needs to be added: process_aN([ process_all([Hl ],Result). 1Tl],[H2 / T2):process_one(Hl,H2), proces_all(Tl where process- one/Z ,T2). takes zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Hl as input and returns H2 as output. Note that, in the above, we have: added an extra argument to both process- all and to process- one; and composed the required result argument in the head of the second clause. Spotting that process- one should be changed is tricky: the system cannot easily make the decision for the student until the required result argument is composed. The system could provide a range of options for making various instantiations-but now the student needs help to explore the space of possible programs in order to choose the right one. Even after all this work. we are not finished. Next, we add a context parameter argument: process_all([ process_all([Hl ],L,Result). JTl],L,[H2 process_ 1T2):one (H 1, H2), process_afl(Tl ,L,T2). Seeing the middle argument of append/3 as to be familiar with the terminology used in for the student. We now instantiate Result to L; and also does fine here); and process- all to append. a context modifying parameter suggests that the student needs the schema. This is likely to be a problem instantiate process- one This yields: to the identity relation (=/2 append([ l,L,L). append([H 1 ITl],L,[H2 I T2):Hl =H2, append(T 1,L,T2). These steps are moderately straightforward. From some personal experience with such a system, the student will need to be provided with a powerful undo facility. Students may well make exploratory moves and only after making the move realize that the result is not what is wanted. There is some hope here that providing an explicit representation of the program’s development-akin to AlgebraLand’s interface[20]-would be of considerable help. 8. RELATED WORK Plummer has developed a cliche-based tool which is intended for use by experienced Prolog programmers[7]. His approach requires that cliches are defined in a way equivalent to a second order predicate logic form. The programmer has to specify how to instantiate the cliche. Technically, the work that is closest to Robertson’s approach is that of Kirschenbaum et al. [ 191. They are also exploring the notion of using techniques for program development. They make claims that their approach can be applied to introductory courses on software engineering and that this has been successful-although they do not appear to have produced a software tool yet. Their approach to program development requires that a program ‘skeleton’ is selected which has the precise flow of control desired to solve the current programming task. The programmer then enhances the basic skeleton without altering the flow of control. The permitted enhancements are the application of the various techniques. If more than one technique is to be applied then the result of each application is produced and these results merged together. The main work outwith the Department of Artificial Intelligence that we know about is aimed at the novice programmer. Gegg-Harrison has designed a schema-based editor for list-processing Prolog techniques 117 tasks[21]. His system is a relative of the techniques-based editor. It makes use of 14 basic schemata for manipulating a large number of list processing tasks. Gegg-Harrison intends the eventual construction of an Intelligent Teaching System for Prolog. 9. CONCLUSION A new design based on ideas found in Robertson’s prototype and the recursion editor is being developed which should mitigate some of the problems identified in this paper. A first version of this system, called TED (Techniques Editor), has been built by Andy Bowles using LPA MacProlog, and will be used as part of a formative evaluation by Tom Ormerod and Linden Ball at Loughborough in the very near future. Part of the design is aimed at providing a mechanism by means of which novices can drive technique selection via browsing through examples of problems and their solution. At Loughborough, there are plans to carry out an evaluation of the editor in terms of how it affects the development of programming expertise. This work will be carried out by Linden Ball and Tom Ormerod at Loughborough University and Hank Kahney at the Open University. We therefore hope that the educational costs and benefits associated with the use of the techniques-based approach will be clearly mapped out. Ackno\rledgemen/s-This paper is a contribution to future work on the development of a Prolog programming techniques editor designed for effective use by novices. Thanks are therefore due to my colleagues-particularly to Dave Robertson, Andy Bowles and Helen Pain-and to Tom Ormerod and Hank Kahney. Thanks are also due to Alan Bundy, Tom Green, Richard O’Keefe and Leon Sterling for discussions about the nature of Prolog programming techniques and their possible utility. Any deficiencies in this paper are all my own work and should not be attributed to anyone else. This research was partially supported by the Joint Council Initiative in Cognitive Science and Human-Computer Interaction Grant No. G9030396. REFERENCES 4. 5. 6. 7. 8. 9. 10. II. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Briggs J. H., Why teach PROLOG? The uses of PROLOG in education. In PROLOG, zyxwvutsrqponmlkjihgfedcbaZ Children and Students (Edited by Nichol J., Briggs J. and Dean J.), Chap. II, pp. 113-120. Kogan Page, London (1988). Bundy A., Teaching AI programming to non-scientists. In Proceedings of the 2nd International Conference on ArtiJicial Intelligence and Education, Univ. of Exeter, pp. 1619 (1985). Ormerod T. C., Manktelow K. I., Steward A. P. and Robson E. H., The effects of content and representation on the transfer of PROLOG reasoning skills. In Lines of Thinking: Rejeclions on the Psy chology of Thought (Volume I)(Edited by Gilhooly K. J., Keane M. T. G., Logie R. H. and Erdos G.), Chap. 19, pp. 2677281. Wiley, Chichester (1990). Green T. R. G., Programming languages as information structures. In The Psy chology of Programming (Edited by Hoc J-M., Green T. R. G., Gilmore D. J. and Samurcay R.), Chap. 2.2, pp. 117-137. Academic Press, London (1990). Kahney H., An In-Depth Study Of The Cognitive Behaviour Of Novice Programmers. Unpublished Ph.D. thesis, Human Cognition Research Laboratory, The Open University, Milton Keynes (1982). Waters R. C., KBEmacs: A Step Toward the Programmer’s Apprentice. Technical Report 753, MIT Artificial Intehgence Laboratory (1985). Plummer D., Cliche programming in Prolog. In Proceedings of the M ETAW orkshop, META-90, Leuven, Belgium (I 990). Johnson W. L. and Soloway E., PROUST: knowledge-based program understanding. IEEE Trans. Software zyxwvutsrqpo Eng ng SE-IL 267-275 (1985). Johnson W. L., Inrenrion-Based Debugging of Novice Programming Errors. Pitman, London (1986). Spohrer J. C., Soloway E. and Pope E., A goal-plan analysis of buggy Pascal programs. Human-Computer Interaction 1, 163- 207 (1985). Rist R. S., Plans in programming: definition, demonstration, and development. In Empirical Studies of Programmers (Edited by Soloway E. and Iyengar S.), pp. 2847. Ablex, New Jersey (1986). Gilmore D. J. and Green T. R., Programming plans and programming expertise. Q. J. Exp. Psycho/. 40,423442 (1988). Rist R. S., Schema creation in programming. Cognitive Sci. 13, 389414 (1989). Gilmore D. J., Expert programming knowledge: a strategic approach. In The Psy chology of Programming (Edited by Hoc J-M., Green T. R. G., Gilmore D. J. and Samurcay R.), Chap. 3.2, pp. 223- 234. Academic Press, London (1990). du Boulay J. B. H., O’Shea T. and Monk J., The blank box inside the glass box: presenting computing concepts to novices. Int. J. M an M achine Stud. 14, 237-249 (1981). Laird J. E., Rosenbloom P. and Newell A., Chunking in SOAR: the Anatomy of a General Learning Mechanism. Research Report CMU-CS-85-154, Department of Computer Science, Carnegie-Mellon University (1985). Bundy A., Grosse G. and Brna P., A recursive techniques editor for Prolog. Instruct1 Sci. 20, 135-172 (1991). Robertson D., A simple Prolog techniques editor for novice users. In 3rd UK Annual Conference on Logic Programming (Edited by Wiggins G. A., Mellish C. and Duncan T.), pp. 19&205. Springer, Berlin (1991). Kirschenbaum M., Lakhotia A. and Sterling L., Skeletons and Techniques for Prolog Programming. TR 89-170, Case Western Reserve University (1989). Foss C. L., Learning from Errors in AlgebraLand. IRL Technical Report 3, Institute for Research on Learning, Xerox Palo Alto Research Center (1987). Gegg-Harrison T. S., Learning Prolog in a schema-based environment. Instruct/ Sci. 20, 173- 192 (1991).