Int. J. Human-Computer Studies (2001) 54, 285}300 doi:10.1006/ijhc.2000.0433 Available online at http://www.idealibrary.com on
Visual representations for recursion SHO-HUAN TUNG AND CHING-TAO CHANG Department of Information Management, National Yunlin University of Science and Technology, Touliu, Taiwan WING-KWONG WONG Department of Electronics, National Yunlin University of Science and Technology, Touliu, Taiwan JIHN-CHANG JEHNG Institute of Human Resource Management, National Central University, Chungli, Taiwan (Received 24 March 1997 and accepted in revised form 30 June 2000) Visualcode is a visual notation that uses coloured expressions and graphical environments to describe the execution of Scheme programs. RainbowScheme is a program visualization system which is designed to produce visualcode representations of step-bystep execution of Scheme programs. This article presents a new approach of teaching recursion using visualcode and RainbowScheme. Experimental evaluation indicates that viewing RainbowScheme-produced visual traces and requiring students to use visualcode to generate visual evaluation steps of recursive programs can enhance the learners' ability to evaluate recursive programs as well as to solve recursive programming problems. 2001 Academic Press KEYWORDS: program visualization; recursion; Scheme.
1. Introduction Recursion is an important concept that is widely used in a variety of programming problems (McCraken, 1987). Unfortunately, there are a few di$culties that make recursion di$cult to learn and to teach (Kurland & Pea, 1983; Widenbeck, 1989). First, recursion is not a concept that we can "nd an analogy in everyday life to help to explain (Pirolli & Anderson, 1985). Second, executing a recursive call also requires large memory resources which humans may not possess (Er, 1984). In addition, novices have di$culties with the idea of passive control passing (Kurland & Pea, 1983). They mistakenly think that once the base case has been reached the processing stops rather than returning the control to the caller. The di$culties of learning recursion have motivated many researchers to study students' behaviours and to build tools to aid their comprehension (Papert, 1980; Turkle, 1984; Bhuiyan, Greer & McCalla, 1991). A competent recursive problem solver not only needs complete understanding about the execution of recursive programs but also needs the ability to develop solutions to a wide variety of recursive programming problems. For most other programming 1071-5819/01/030285#16 $35.00/0
2001 Academic Press
286
S.-H. TUNG E¹ A¸.
concepts, understanding their semantics is often a prerequisite for using them in solving real problems. Recursion seems to be an exception. Most learners are required to write recursive programs before fully understanding their behaviours. Due to the stereotype nature of many recursive programming problems, instructors usually use example recursive programming problems augmented with &&canned'' problem-solving strategies to teach students. Surprisingly, some students are able to solve similar problems without even understanding how the recursive programs work. Many empirical "ndings have suggested that learning to evaluate recursive programs does not necessarily aid students in writing recursive programs (Pirolli, 1986; McKendree and Anderson, 1987; McKendree, 1990). This may be true for traditional evaluation methods, which are too low-levelled to allow students to capture the &&big picture'' of recursive evaluation, and stereotype recursive programming problems, which can be solved using &&canned'' problem-solving strategies. However, it may not apply to advanced visual evaluation methods nor to non-stereotype recursive programs. Further, there are contradictory "ndings that a lack of ability to reason causally about programs interferes with the successful construction of working programs (Reiser, 1987; Reiser Kimberg, Lovett & Ranney, 1992). Reasoning causally about a program's execution is indispensable in debugging the program. This article presents a visual-oriented approach of teaching recursion that employs a visual execution notation called visualcode and a program visualization system called RainbowScheme (Tung, 1998). Visualcode is developed for the Scheme programming language to describe its operational semantics (Rees & Clinger, 1991). RainbowScheme allows visual execution of Scheme programs to be presented automatically according to visualcode rules. A signi"cant aspect of the experiment presented in this arcticle is that students are required to generate their visualizations of recursive programs using visualcode. Evaluation results show that viewing RainbowScheme-produced program traces and generating visual execution steps using visualcode can signi"cantly improve the students' ability to evaluate recursive programs and to solve recursive programming problems.
2. Related work Many educators and researchers have tried to convey the idea of recursion using a variety of visual models. These visual models range from the Russian Doll (Hofstader, 1979; Bowman & Seagraves, 1985) to a painter painting a picture of himself painting a picture (Harvey & Wright, 1994). Unfortunately, these models do not convey recursion as a computation containing a series of &&unfolding'' and &&returning'' steps for achieving some goal (Wiedenbeck, 1989). Furthermore, relying on these incomplete visual models is dangerous and error prone, since a correct and detailed understanding of recursion should be based on the operational semantics of a programming language (Bonar & Soloway, 1985). One di$culty for students learning recursion is that they fail to recognize that each di!erent recursive call actually activates a new copy of the called procedure with slightly di!erent input data. To alleviate this problem, Murnane (1991) described an approach for making this copy model visible. Upon making a recursive call, this method copies a new version of the procedure at the call point. The values of the arguments to the
VISUAL REPRESENTATIONS FOR RECURSION
287
procedure are placed in a &&bucket'' associated with each new copy to emphasize the fact that each copy is slightly di!erent from the previous one. The Recursion Animator, however, adopts a slightly di!erent approach that uses overlaid instantiation windows to present the copy model (Wilcocks and Saunders, 1994). Each window contains bindings of variables for each activated procedure. A single copy of the procedure is presented below the overlaid windows to allow visual association between variables and their values. These approaches, however, are unable to show the nesting of operations that needs to be performed after recursion returns. Furthermore, passively viewing an animation of the execution of a computer program is not su$cient to enhance the learners' understanding of that program. A more e!ective approach of learning a computer program is to actively participate in the construction of its visualization (Stasko, 1998). In addition to visual methods, LISPITS and LISP Tutor adopt a di!erent approach that focuses on the logical structure of recursive programs by bringing a student through the reasoning behind the termination case and recursive cases (Pirolli, 1986; Corbett & Anderson, 1992). LISPITS and LISP Tutor are based on a cognitive model of human psychology called ACT* (Anderson, 1983) and use production rules organized in a goal tree to arrange the steps used in solving problems. The production rules, however, only specify a set of conditions under which a particular action should be taken, but do not contain visual information as to why that action is e!ective (Reiser et al. 1992). As a result, students using such systems may have di$culties understanding the steps that need to be taken by a recursive program in order to evaluate an answer.
3. Visual representations of evaluation Unlike previous approaches of visualizing recursion, the visualization technique introduced in this article is based on the operational semantics of the Scheme programming language. As a result, visualcode can not only generate dynamic visual representation of recursive evaluation, but can also explicitly present the &&unfolding'' of recursive calls and passing back of the control from callers. With these capabilities, students can better understand detailed steps as well as the &&big picture'' of recursive evaluation, allowing them to debug and program recursive programming problems more e!ectively. Figure 1 presents the subset of visualcode which de"nes semantic rules for the evaluation of applications, lambda expressions, procedure calls, and variable references. These rules are essential to build accurate visualizations of recursive programs. Each semantic rule consists of a left- and a right-hand side. The left-hand side describes an applicable pattern that may be an expression-environment pair or an intermediate
'(E E ...) o(P application rule1 ('E o( 'E o( ...) '(lambda (I ...) E) o( P lambda rule 'I 2 , E, o value( ('I 2 , E, o value( 'v value( ...) P application rule2 'E o[IQv] ...( 'I o( P variable rule 'v value( where v is the value of I in o FIGURE 1. Operational Semantics of a subset of Scheme.
288
S.-H. TUNG E¹ A¸.
representation obtained during evaluation. A matching pattern on the left-hand side is transformed to its corresponding right-hand-side pattern during program evaluation. The Greek letter o is used to represent an environment. Environment is an important semantic concept for the evaluation of Scheme programs. Environments contain bindings of variable names and locations of stored values. Environments can be represented visually as a tree containing frames with di!erent colours that are generated dynamically during program evaluation. The essence of visualcode is best described using these &&visual environments'' and their interactions with the evaluation of Scheme expressions. The application rule1 describes how evaluating the syntactic form (E E ...) in the environment o is transformed to evaluate each of the E's in o. All the E's should be evaluated to values and the left-most E should be evaluated to a procedure. This rule implies that the call-by-value semantics of Scheme that describes the arguments of a procedure application must be evaluated before the body of the procedure. The visualcode representation of this rule is to paint each of the E's with the colour of o:
The lambda rule describes that evaluating the syntactic form (lambda (I ...) E) in o produces a procedure value. The procedure value contains the formal parameters, body, and o. The visualcode representation of a procedure is to use a rectangle, painted with the color of o, to put its formal parameters and body into:
The application rule2 describes that evaluating ('I 2 , E, o value( 'v value( ...) results in evaluating E in a new environment that is formed by extending the original o with bindings of the formal and actual parameters. The visualcode representation of this rule is to allocate a new colour for the extended environment and to paint E using the new colour:
The last rule is the variable rule. The visualcode representation of this rule is to return the value of a variable found by looking up the environment with the colour of the variable. For example, the value of I in the extended environment below is v:
VISUAL REPRESENTATIONS FOR RECURSION
289
In addition to the four rules presented above, the (de"ne I E ) syntactic form establishes a new binding in the global environment. This binding associates I with a new location that stores the value of E. Although these rules are simple, combinations of these rules can produce interesting and coherent visualizations. Figure 2 presents a simple example that utilizes these rules in evaluating an expression containing an application of an anonymous procedure to its arguments. The &&de"ne'' syntactic form puts the bindings for variable a and b into the global environment. Evaluation of the application expression goes through a series of steps which transforms the expression to the "nal answer. During the evaluation, a new environment is created that contains the binding for the formal parameter c and its value 7. Visualcode is especially useful in visualizing recursion. Figure 3 presents an example illustrating how visualcode can be used to capture interesting execution behaviours of recursive programs. The "gure is produced using the RainbowScheme system that supports program visualization with visualcode (Tung, 1998). This program puts a recursive call between two assignment statements. When executed, the assignment statement creates a side e!ect by changing the value of the variable being assigned. Because the order of execution of the assignment statements is di!erent, the resulting values of x and y are also di!erent. The series of the &&unfolding'' process of each recursive call and the passing back of the control from the innermost level to the outermost level of recursion are completely captured in the "gure. The initial values of x and y are the null list. The environments in the "gure present various evaluation contexts of the recursive calls. The example does not display any details of the less-interesting execution steps. Figure 4 presents another example that describes the execution of the factorial procedure. In addition to a few major steps introduced by the application rule, this visual execution also contains minor steps that evaluate the body of factorial in some extended environments. The most important bene"t of the visual trace is that the source step and all intermediate steps are represented using the same &&visual syntax''. This
FIGURE 2. Simple evaluation.
290
S.-H. TUNG E¹ A¸.
FIGURE 3. Recursion with side e!ects.
feature makes each intermediate step and the entire transformation of the program easier to understand. The break point can be set by the user to skip uninteresting evaluation steps. Although the visualcode de"nition seems fairly mathematical, students do not need to understand details of the mathematical de"nitions in order to produce visualcode traces. What is really important is to teach students how to unfold recursive calls using di!rent colours and to extend the environments properly. After the unfolding process reaches the end, the instructor can present to the students the returning process. In our experience, with little practice, students are able to use the visualcode rules to generate their own traces of recursive programs.
VISUAL REPRESENTATIONS FOR RECURSION
291
FIGURE 4. Tracing the factorial procedure.
4. Constructing recursive programs Learners usually hold four di!erent kinds of mental model to develop solutions to recursive programming problems (Bhuiyan et al., 1991). It is speculative that early
292
S.-H. TUNG E¹ A¸.
exposure to the visualcode representation of recursion can avoid developing an improper mental model. By enhancing a deep understanding of the fundamental operating structure and execution of a recursive program with elaborately designed visual information, visualcode can help students develop sophisticated mental models to solve recursive problems. Due to the lack of procedural knowledge of recursion, most novice learners usually hold the #awed loop model when solving recursive problems (Kurland & Pea, 1983; Kahney, 1983). Learners are initially taught some basic declarative knowledge about recursion. For example, a recursive program calls itself or a recursive program has a base case and a recursive case, and so forth. However, the lack of procedural knowledge of recursion results in incorrect application of the more familiar iteration model to recursive problem solving. As demonstrated in the previous section, visualcode explicitly presents the procedural knowledge of recursion, eliminating a potential to develop the incorrect loop model for solving recursive problems. Students may also derive a syntactic model by abstracting syntactic templates out of recursive program examples with similar structures. A typical template contains slots for condition or action parts associated with the base case or the recursive case. However, due to the lack of a &&deep understanding needed for mapping a problem to a recursive construct'', students face di$culties in deriving the condition and action parts properly (Bhuiyan et al., 1991). Visualcode can facilitate students to trace the execution behaviour of a recursive program. As a result, it can help students to diagnose incorrect conditions and action parts e!ectively and develop correct problem solutions. Learners who hold an analytic model usually derive the solution for a programming problem by analysing its input}output behaviour. By demonstrating the process of how a recursive program is evaluated to an answer and providing important clues for deriving the output of a recursive program from its input, visualcode helps induce in students abilities to analyse and predict the execution process of recursive programs with a more re"ned approach. Most complex recursive programs require students to develop an analysis/synthesis model to solve. Although a deep understanding of visualcode does not guarantee students to develop such a sophisticated mental model to solve complex problems, students who have learned visualcode should have better chances to mentally simulate program execution properly and accurately to solve problems. To summarize, successful learners can acquire better problem-solving skills and advance gradually from the naive loop model, to the intermediate syntactic, and "nally to more sophisticated analytic or analysis/synthesis models. A thorough understanding of how a recursive program evaluates an answer using visualcode can help increase the students' ability to form a mental picture to simulate program executions properly. Thus, they are able to develop a solution more accurately.
5. Learning recursion with visualcode To further understand the e!ect of using visualcode and RainbowScheme in teaching recursion, we have conducted a study that evaluates their e!ectiveness in learning recursive programming skills. This section presents results of the evaluation.
VISUAL REPRESENTATIONS FOR RECURSION
293
5.1. METHODS
5.1.1. Participants. Forty-two freshman students from the Department of Information Management at the National Yunlin University of Science and Technology participated in this study. They did not have any previous experience in Scheme nor in recursion. Some of the students had programming experience with one or two traditional languages such as Basic or Cobol. 5.1.2. Materials. The study was conducted while students were taking an introductory programming course. The textbook used in the course was &&The Little LISPer''. This book focuses on programming recursion in LISP or Scheme (Friedman and Felleisen, 1987). A live demonstration of using RainbowScheme to step through a few recursive programs was given to students in the experimental group but not to the control group. 5.1.3. Design. This study employed a randomized block design. Students' entrance exam scores and prior exam grades were used as control variables. The two students with the highest prior exam grades were assigned to block one, the two with the next highest prior exam grades to block two, and so on. The two methods were then randomly assigned to the experimental units. One group (the experimental group) received instructions using visualcode. The other group (the control group) received instruction without using visualcode. Each group had 21 students. 5.1.4. Procedures: Instruction. The course lasted 14 weeks with 3 h of lecture time per week. The 14 weeks of the class were divided into four periods. In the "rst period the instructor introduced fundamental data types, primitive procedures, and user-de"ned procedures. The second period involved solving simple accumulation problems with tailrecursive procedures containing side e!ects. A typical exercise was to compute course averages using students' data stored in a list. The third period illustrated tail recursive and non-tail recursive procedures containing no side e!ects. The fourth period studied advanced recursion that processes deeply nested lists. The class is taught in a laboratory with each student assigned a PC running a simple Scheme programming environment. Students have ample time to practice exercises assigned in class. An exam was given to students at the end of each period, and they were required to develop and test their solutions using computers. Close to the end of the third period, the experimental group received 2 h of instruction on visual tracing using visualcode while the control group was given exercises including traditional programming and evaluation questions to work on their own. The experimental group was presented with visual tracing of the &&unfolding'' and &&returning'' of recursive call using the blackboard and colour pens to produce traces similar to Figures 3 and 4. After that, a live demonstration of the RainbowScheme was given to students. They were then asked to practise evaluation exercises similar to the demonstrated examples using paper and pencils. No details of using the Rainbow Scheme were given to students, and none of them were given an opportunity to use the system. The bene"t of using paper and pencil rather than using the RainbowScheme to work through the
294
S.-H. TUNG E¹ A¸.
examples was that students were forced to think on their own rather than relying on the RainbowScheme to provide them with answers. Although some of the students did not produce correct answers, solutions of the exercises as well as their visual traces were presented again to the students. This step gave those students who did not answer correctly an additional opportunity to better understand the execution behaviours of recursive programs. Post-test. The post-test was given at the end of the third period using material containing seven evaluation questions and eight programming questions. Many of the questions were designed so that a clear understanding of the &&unfolding'' and &&returning'' sequences of recursion could help to derive the solutions. These questions are given in the appendix. Students were not allowed to use computers while answering evaluation questions; however, they were required to use the computer to solve programming questions. Partial answers were not accepted and the students had to produce correct answers in order to obtain credits for the programming questions.
5.2. DATA ANALYSIS AND RESULTS
A t-test was conducted to examine the di!erences between the means of the post-test for the two groups. The results showed that students in the visual group signi"cantly outperformed those who were in the control group in both evaluation questions and programming questions with t"8.142 (p(0.05) and t"3.069 (p(0.05), respectively. The average scores of the evaluation questions for the visualcode group and the control group were 5.10 and 1.67, respectively. The average scores of the programming questions for the visualcode group and the control group were 5.67 and 3.57, respectively. Table 1 shows the results of the analysis. In addition to overall performance, we were also interested in "nding out which individual evaluation or programming questions were more sensitive to visualcode representation of recursion. t-tests were done on each question to investigate the di!erences between the means for the two groups. The results indicated that the visualcode group signi"cantly outperformed the control group on all individual evaluation questions (p(0.05). For programming questions, the visualcode group performed signi"cantly better than the control group on questions 2, 6, 7 and 8 (p(0.05). The results closely matched our prediction, since all the evaluation questions and three of the four programming questions (6, 7 and 8) showed signi"cance which depended heavily on the understanding of the sequence of &&unfolding'' and &&returning&& in order to be answered correctly. For &&stereo-typed'' questions such as questions 1, 3 and 4, the TABLE 1 Students1 performance on the post-test measure
Evaluation Programming
Visualcode (n"21)
Control (n"21)
t-test Prob.
5.10(1.61)* 5.67(2.29)
1.67(1.06) 3.57(2.13)
8.142 0.0001 3.069 0.0039
* Mean score with standard deviation in parentheses.
295
VISUAL REPRESENTATIONS FOR RECURSION
TABLE 2 Students1 performance on individual evaluation questions Mean(V/C)
STD(V/C)
Q1 Q2 Q3 Q4 Q5 Q6 Q7
0.48/0.00 0.44/0.33 0.50/0.00 0.50/0.00 0.00/0.40 0.22/0.51 0.22/0.44
0.67/0.00 0.76/0.0952 0.38/0.00 0.38/0.00 1.00/0.81 0.95/0.52 0.95/0.24
t-test Prob. 6.325* 5.764* 3.508* 3.508* 2.169* 3.530* 0.708*
0.0001 0.0001 0.0011 0.0011 0.0361 0.0011 0.0001
*p(0.05.
TABLE 3 Students1 performance on individual programming questions Mean(V/C)
STD(V/C)
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8
0.22/0.30 0.40/0.50 0.40/0.46 0.44/0.50 0.51/0.40 0.46/0.48 0.40/0.51 0.48/0.00
0.95/0.90 0.81/0.38 0.81/0.71 0.76/0.62 0.48/0.19 0.71/0.33 0.81/0.43 0.33/0.00
t-test Prob. 0.587 3.069* 0.712 0.989 2.011 2.609* 2.697* 3.162*
0.5604 0.0038 0.4809 0.3286 0.0511 0.0127 0.0102 0.0030
*p(0.05
visualcode group performed just slightly better than the control group. Results of students' performances on all the questions are given in Tables 2 and 3. It would be interesting to understand the long-term impact of the experiment treatment between the two groups by giving an analysis on the scores of the "nal exam. However, in order to be fair to students in both groups taking the course, the control group also received similar training using visualcode shortly after the experiment, making such an evaluation inappropriate.
5.3. DISCUSSION
Results of this study support the claim that asking students to view visual execution steps produced by RainbowScheme and later requiring them to reproduce those steps manually for similar problems can assist students to understand the concept of recursion e!ciently. In particular, students' problem-solving skills in evaluating recursive programs and solving recursive programming problems improved signi"cantly. The reasons that account for the signi"cant e!ect of using visualcode on learning recursion may vary. First, visualcode and RainbowScheme can explicitly display intermediate steps of recursive procedures; this allows students to analyse and understand the conceptual structure of recursion quickly. More importantly, the students'
296
S.-H. TUNG E¹ A¸.
understanding of recursion was strengthened by actively producing execution steps of a few recursive programs themselves. Without the help of visualcode to represent recursion, it would be more di!cult for students to understand the inner working of a recursive program by looking at the source code. In addition, visualcode could help reduce the students' cognitive load and free students from the burden of excessive low-level and tedious cognitive operations. As a result, more working memory can be released to perceive high-level execution process of the recursive procedures that makes in-depth understanding of recursion possible. Finally, visualcode-generated dynamic representations can represent di!erent aspects of recursion and make the knowledge analysable. The form of the visual information can represent the temporal features and logical relations of transitions so that the student can readily see how recursive procedures are executed and can mentally simulate those processes. The student can also compare run-time phenomena of di!erent types of recursive procedures making the concept of recursion more analysable.
6. Conclusion Appropriate use of visualization techniques should improve our ability to understand computer science concepts in many areas. Surprisingly, a number of prior studies have found that using animation and visualization to help in teaching those concepts has less bene"cial e!ects on learning than hoped for (Stasko, 1998). A plausible explanation might be that inappropriate methods of instruction prevent participants from receiving the bene"ts. Consistent with the "nding reported by Stasko, the experiment presented in this article showed bene"cial e!ects by requiring active participation of students in constructing visualization. Visualcode and RainbowScheme provide a useful set of high-level rules to enable students and instructors to construct visualizations. The instructor can express the dynamic execution of recursive programs more easily. Students can also use those rules to hand simulate the execution of a recursive program. In addition, they can also communicate more e!ectively using visible objects generated with those rules. Unlike most other programming techniques, students learning recursion are usually faced with the problem of having to write recursive programs before completely understanding their behaviours. The primary contribution of using visualcode and RainbowScheme to teach recursion is that it provides a correct and complete description of recursive computation based on the semantics of the Scheme programming language. In addition, it helps to improve students' ability to evaluate and solve recursive programming problems by presenting recursion as a computation containing a series of unfolding and returning steps for achieving some goal. Dynamic visualization is especially useful to bridge the gap between static program code and its dynamic behaviour. Object-oriented programming is another important concept for programmers to understand. It would be interesting to study the e!ect of visualizing object-oriented programs on understanding and constructing such programs. The authors would like to thank anonymous reviewers for their suggestions on earlier drafts of this article. This research is supported by a grant from the National Science Council of Taiwan under contract No. NSC 85-2511-S-224-017 CL and NSC 86-2213-E-224-004.
VISUAL REPRESENTATIONS FOR RECURSION
297
References ANDERSON, J. R. (1983). ¹he Architecture of Cognition. Cambridge, MA: Harvard University Press. BHUIYAN, S., GREER, J. E. & MCCALLA, G. I. (1991). Characterizing, rationalizing, and reifying mental models of recursion. Proceedings of 13th Cognitive Science Society Conference, pp. 120}126. Chicago, IL. BONAR, J. & SOLOWAY, E. (1985). Pre-programming knowledge: a major source of misconceptions in novice programmers. Human-Computer Interactions, 1, 133}161. BOWMAN, B. C. & SEAGRAVES, K. (1985). Picturing recursion. Computing ¹eacher, 1, 28}31. CORBETT, A. T. & ANDERSON, J. R. (1992). LISP intelligent tutoring system: research in skill acquisition. In J. H. LARKIN & R. W. CHABAY, Eds. Computer-Assisted Instruction and Intelligent ¹utoring Systems: Shared Goals and Complementary Approaches. pp. 73}109. New Jersey: Lawrance Erlbaum Associates, Inc. ER, M. C. (1984). On the complexity of recursion in problem-solving. International Journal of Man}Machine Studies, 20, 537}544. FRIEDMAN, D. P. & FELLEISEN, M. (1987) ¹he ¸ittle ¸ISPer, Cambridge, MA: The MIT Press. HARYEY, B. & WRIGHT, M. (1994). Simply Scheme. Cambridge, MA: The MIT Press. HOFSTADER, D. (1979). Godel, Escher, Bach: An Eternal Golden Braid. New York: Basic. KAHNEY, H. (1983). What do novices know about recursion. CHI183 Conference Proceedings, pp. 235}239, Boston, MA. KURLAND, D. M. & PEA, R. D. (1983). Children's mental models of recursive LOGO programs. Proceedings of the 5th Annual Conference of the Cognitive Science Society, pp. 1}5, Rochester, NY. MCCRAKEN, D. D. (1987). Ruminations on computer science curricula. Communications of the ACM, 30, 3}4. MCKENDREE, J. (1990). E!ective feedback content for tutoring complex skills. Human Computer Interactions, 5, 381}413. MCKENDREE, J. & ANDERSON, J. R. (1987). E!ect of practice on knowledge and use of basic lisp. In J. M. CARROLL, Ed. On Interfacing ¹hought. Cambridge, MA: MIT Press. MURNANE, J. (1991). Models of recursion. Computers Education, 16, 197}201. PAPERT, S. (1980). Mindstorms: Children, Computers, and Powerful Ideas. New York: Basic. PIROLLI, P. (1986). A cognitive model and computer tutor for programming recursion. Human}Computer Interaction, 2, 319}355. PIROLLI, P. L. and ANDERSON, J. R. (1985). The role of learning from examples in the acquisition of recursive programming skills. Canadian Journal of Psychology, 39, 240}272. REES, J. & CLINGER, W. (Editors) (1991). Revised report on the algorithmic language Scheme. ¸isp Pointers, 4, 1}55. REISER, B. J. (1987). Causal models in programming, Paper presented at ¹he 3rd International Conference on Arti,cial Intelligence and Education, Pittsburg, PA. REISER, B. J., KIMBERG, D. Y., LOVETT, M. C. & RANNEY, M. (1992). Knowledge representation and explanation in GIL, an intelligent tutor for programming. In J. H. LARKIN & R. W. CHABAY, Eds. Computer-Assisted Instruction and Intelligent ¹utoring Systems: Shared Goals and Complementary Approaches, pp. 111}150. NJ: Lawrance Erlbaum Associates, Inc. STASKO, J. (1998). Empirically assessing algorithm animations as learning aids, In STASKO, DOMINGUE, BROWN & PRICE Eds. pp. 419}438, Chapter 28, Software
298
S.-H. TUNG E¹ A¸.
Appendix EVALUATION QUESTIONS: (define x 0) (define foo (lambda (ls) (cond ((null? ls) (set! x 0)) ((' (car ls) 0) (begin (foo (cdr ls)) (set! x (# x (car ls))))) (else (begin (set! x (# x (car ls))) (foo (cdr ls))))))) Q1. What is the value of ‘‘x’’ after evaluating (foo ’(2 3 !3 4 !5 2))? (define y ’()) (define goo (lambda (ls) (cond ((null? ls) y) ((atom? (car ls)) (begin (goo (cdr ls)) (set! y (cons (car ls) y)))) (else (begin (set! y (car ls)) (goo (cdr ls))))))) Q2. What is the value of ‘‘y’’ after evaluating the following expression? (begin (set! y ’()) (goo ’(a b c))) Q3. What is the value of ‘‘y’’ after evaluating the following expression? (begin (set! y ’()) (goo ’(a b (x y) z))) Q4. What is the value of ‘‘y’’ after evaluating the following expression? (begin (set! y ’()) (goo ’(a b (x y) z (u)))) (define bar (lambda (ls) (cond ((null? ls) 1) ((number? (car ls)) (* (car ls) (bar (cdr ls)))) ((list? (car ls)) (#(caar ls) (bar (cdr ls)))) (else (bar (cdr ls)))))) Q5. What is the result of evaluating (bar ’((2) (3) (4)))? Q6. What is the result of evaluating (bar ’(a 2 (5) a 3))? Q7. what is the result of evaluating (bar ’(2 3 (6 u) 5 (7)))?
VISUAL REPRESENTATIONS FOR RECURSION
PROGRAMMING QUESTIONS: BEGIN and SET!are not allowed in questions 1, 2, 3, 4, 6, and 7. Q1. Write procedure REM-NEGATIVE. Test your procedure on: (REM-NEGATIVE ’()) N () (REM-NEGATIVE ’(!32 3)) N (3) (REM-NEGATIVE ’(2 !32 3 !9)) N (2 3) Q2. Write procedure PICK-BELOW. Test your procedure on: (PICK-BELOW (PICK-BELOW (PICK-BELOW (PICK-BELOW (PICK-BELOW
3 3 2 4 0
’(1 ’(x ’(a ’(0 ’(3
2 3 4 5)) N (1 2 3) o d a b)) N (x o d) b c d e)) N (a b) 1 2)) N (0 1 2) 4)) N ()
Q3. Write procedure PRODUCT-SUM. Test your procedure on: (PRODUCT-SUM ’((2 3) (2 4) (3 4))) N 6#8#12 N 26 (PRODUCT-SUM ’((2 3) (2 4))) N 6#8 N14 (PRODUCT-SUM ’()) N 0 Q4. Write procedure FIND-VALUE. Test your procedure on: (FIND-VALUE ’x ’((c 3) (d 7) (x 9) (y 10))) N(x 9) (FIND-VALUE ’y ’((c 3) (d 7) (x 9) (y 10))) N (y 10) (FIND-VALUE ’z ’((m 0))) N Cf Q5. Write SUM-AVERAGE, so that executing (SUM-AVERAGE ’((2 3 4) (5 6 7) (1 2 3))) prints the following output on the screen: Current accumulation: 2 3 4 Current accumulation: 7 9 11 Current accumulation: 8 11 14 Average: 8/3 11/3 14/3 Q6. Write procedure FOO which performs addition or multiplication interchangeably. Test your procedure on: (FOO 0) N 0 (FOO 1) N (#10)"1 (FOO 2) N(* 2 (#10))"2 (FOO 3) N (#3 (* 2 (#10)))"5 .... Q7. Write procedure BAR which performs addition or multiplication over a list of numbers depending on whether the number is
299
300
S.-H. TUNG E¹ A¸.
positive or not. Test your procedure on: (BAR ’()) N 0 (BAR ’(2 3 !4 9 !5)) N (* 2 (* 3 (#!4 (* 9 (#!5 0))))) N!294 (BAR ’(3 0 9 !5))N (* 3 (#0 (* 9 (#!5 0)))) N !135 Q8. Write procedure SUM-AVERAGE2, so that executing (sum-average2 ’((2 3 4) (5 6 7) (1 2 3))) prints the following output on the screen: Accumulation in reverse order: 1 2 3 Accumulation in reverse order: 6 8 10 Accumulation in reverse order: 8 11 14