Resolving Color Con icts During Color Uni cation 1 ...

Resolving Color Con icts During Color Uni cation Anthony J. Kusalik and Eric Neufeld Department of Computer Science University of Saskatchewan Saskatoon, Saskatchewan, Canada, S7N 0W0 fkusalik,[email protected]

Abstract

Color uni cation is valuable for tracing, debugging, and understanding Prolog programs. However, color con icts can arise naturally during color uni cation. This paper describes possible strategies to deal with these con icts. The advantages and disadvantages of the dierent strategies are discussed using examples generated by a working implementation. It is found that no single scheme works best in all situations, and that in many instances, more complex schemes have little advantage over simpler ones.

Keywords:

visualization of Prolog (program) execution, uni cation

1 Introduction The same features that give Prolog its powerful semantics also make it dicult to learn and debug. The common 4-port model [Byrd80] is of limited assistance since it does not correspond to Prolog's declarative execution model. Furthermore, the 4-port debugger typically provides information in low bandwidth textual form. This results in confusion, dissatisfaction, and ineciency for users, especially novices. A tree is a natural way to represent and understand Prolog computations. Most systems for graphically visualizing Prolog [Boja89, DeCl86, EiBr88] utilize either a proof tree or search tree as their basic framework. Most focus on portraying success or failure of clauses and backtracking. Although they typically show uni cation of a subgoal and a clause head, these systems provide little visual information about the eect of uni cation on the rest of the tree. Uni cation plays a critical role in a Prolog program's execution; uni cation of logic variables can result in complex ows of information. Thus, a good visualization of uni cation would be a great aid to program understanding. A new system called Color Prolog [Dob+96] has been devised to address these issues, and speci cally to help users understand the eects of uni cation. The system employs color tagging and a dynamic proof tree to help visualize execution. A user can dynamically tag a term or subterm with a color. This color is immediately propagated backwards and forwards through the tree, according to the pattern of uni cations that have been made. As the tagged item is further uni ed with other terms, its color is propagated through the tree. This lets a user trace the in uence of the tagged item during program execution by following the progression of its color. To support color tagging, color attributes are associated with (Prolog) terms and uni cation is extended to unify these attributes. The extended procedure is called color uni cation. While tracing a Prolog execution with Color Prolog, two dierently colored terms may be uni ed. Such color con icts arise quite naturally. There are dierent ways to deal with color con icts, some more complex than others. This paper presents and compares several con ict resolution mechanisms, and gives examples of each. The mechanisms vary in complexity (both 22

implementational and visual), ability to handle dicult cases, and ability to retain information (despite the con ict). It is found that while more complex techniques have certain potential, simple strategies are often best.

2 Color Prolog Color Prolog helps users to understand and debug Prolog programs, and in particular, to understand the eects of uni cation.

2.1 Visualization Model

Color Prolog provides a graphical, dynamic, and active visualization by representing the computation as (construction of) a proof tree, providing color tagging, and implementing color uni cation. User interaction includes tagging of terms with color:  The user can color a term in an initial query and observe the propagation of that color as execution progresses.  At any step in the computation, the user can color a term \on the y" and see the binding instantly propagated through the tree (across the existing steps of the computation). Subsequent steps in the computation will propagate the new color tag.  The user may also un-tag or undo the color tagging of a term at any time. Terms with the same color tag (due to uni cation or shared variables) are joined by connecting color bands to visually convey the ow of information induced by uni cation and logic variables. Any term or subterm can be tagged. Further, the components of a functional (complex) term can be tagged with dierent colors, and dierently from the functor itself.

2.2 Achieving Color Tagging

To implement color tagging and color uni cation, the usual implementation of Prolog is extended to allow each term (including atoms, complex terms, and variables) to have a color attribute. Color attributes are similar to meta-terms [Neum90] that can be associated with variables in Prolog systems such as ECLiPSe [ECRC96] or SICStus Prolog [SICS96]. However, meta-terms are only associated with variables, whereas color attributes are associated with all types of terms, including ground ones. Further, a variable retains its color attribute even after being bound to a non-variable. The uni cation algorithm is extended to unify color attributes whenever two terms successfully unify. An important point is that color uni cation must succeed whenever normal uni cation would. Hence, three cases arise: A. Neither term has a color. In this case, the terms are made to share the same color attribute, though the attribute is not manifest at this point. This allows the user to color and un-color terms later to view relationships among dierent variables or terms. B. Only one term has color. The uncolored term takes on the color of the colored term. C. Both terms have a color. If the colors are the same, the two terms are made to share the same color attribute. Otherwise there is a color con ict. Resolution of color con icts is the interesting case, and is the focus of this paper.

23

2.3 Current Implementation

A prototype of this Prolog visualization system has been implemented in C using X-windows. The interpreter follows the design of Maier and Warren [MaWa88] using, for instance, a structure-copying scheme for representation of terms. Two interfaces are used: a terminalbased one, for entering queries and giving the results of those queries, and a graphical window for viewing the computation, tagging terms, and controlling execution via buttons. Mouse clicks while the cursor is positioned over a term are used to actually tag terms. Buttons are available to step forward in the computation, \leap" forward to the next failure, force failure (for a new solution), accept a new query, and abort the current execution. Color tagging of terms is implemented as a toggle. That is, if a term is already tagged with a certain color, re-tagging it with the same color undoes the tag. This can be understood as \clearing" the color associated with the term, and is rendered in that manner in the graphical window. Current restrictions on the implementation include:  Only three colors are supported for tagging | red, green, and blue.  The interpreter supports pure Prolog plus a few, select built-in predicates such as cut (!). Numeric terms and arithmetic operators are not yet supported.  Some restrictions on syntax apply, especially on output. For example, the usual support for Prolog in x operators is not yet present. Many of these restrictions are being addressed in current implementation eorts.

2.4 Using Color Prolog

Initial results with Color Prolog suggest that its visualizations of Prolog program behaviours are not only interesting, but also helpful to learners and users for understanding Prolog execution and debugging their programs. Execution behaviors are captured not only in the instantaneous images in the graphical window, but also by the animation (successive images) presented during an entire (portion of) program execution. The visualizations help in understanding the basic recursive (control) structure in most Prolog programs, the ow of information (e.g. data ow) through variables and arguments, and the operation of complex data structures. They are also eective in debugging programs with in nite loops (in nite recursion), data ow errors, variable-naming errors, and unexpected failure due to logic errors. A small example here gives a avor of what is possible with the system. More detail is presented elsewhere [Neu+97]. Dierence lists are often used in Prolog programs for eciency, but are typically dicult for beginning users to understand, write, and debug. Here, the dierence-list formulation for the reverse predicate (the predicate for reversing the elements of a list) is used to illustrate the power of color tagging and Color Prolog. Figure 1 illustrates a visualization of reverse/3. Figure 1(a) gives the original program, Figure 1(b) shows the original query with terms in the input list colored, and Figures 1(c) and 1(d) contain successive images illustrating the propagation of color tags and the addition of tagged terms to the partial result by recursive calls. Figure 1(e) shows computation at the base case where the colors of the tagged terms moved up the tree to the answer variable. After the computation was complete (i.e. the query was successfully resolved), the last argument was tagged with blue. The resulting immediate propagation of color indicates how the binding of that argument (a variable in the original query) was made.

24

reverse([],X,X). reverse([H|T],X,Y) :reverse(T,[H|X],Y).

(a)

(b)

(c)

(d)

(e)

(f)

Figure 1: Basic color tagging, illustrated using the reverse/3 predicate

3 Color Con ict As discussed in Section 2.2, color con icts may arise during visualization. A color con ict occurs when two dierently colored terms must unify (according to the semantics of the language). Obviously, the uni cation must succeed, but the issue is choosing the color tag to be associated with the uni ed terms. This section presents, explores, and compares several possible solutions. Color con ict cannot occur on immediate propagation of color (when the user tags a term, and the tag is instantly propagated in the image to terms with which color sharing has been established through color uni cation). Rather, it occurs on uni cation during resolution steps.

3.1 Examples of Color Con ict

An example of color con ict can be shown using the reverse/3 predicate (recall Figure 1). Suppose the user colors the initial query as shown in Figure 2(a). After two steps, the empty list is all that remains of the rst argument and the resolution is about to succeed (Figure 2(c)). The next step requires uni cation of a variable tagged blue (the third argument) with a list containing elements tagged with other colors (the second argument). A color con ict arises, and the solution to the con ict determines the graphical appearance of the next step in the computation. As another example, consider a predicate p/2 about which a user knows little. Initially, the arguments of p/2 are all uninstantiated, and the user tags each with a dierent color (Figure 3(a)). After several steps, the computation is as shown in Figure 3(b). The two variables have been instantiated to atoms (each being the atom 1), and subgoal t(1,1) is about to be called. 25

(a)

(b)

(c)

Figure 2: Color con ict, illustrated using the reverse/3 predicate

(a)

(b)

Figure 3: Color con ict, illustrated using the p/2 predicate Unbeknownst to the user, the de nition of t/2 uni es its two arguments; i.e. the de nition of the predicate is t( Same, Same ) :- ...

The uni cation will succeed. However, the tags of the two arguments dier, so there will be a color con ict.

3.2 Solution Mechanisms

The current implementation of Color Prolog supports four dierent con ict resolution mechanisms: (1) con ict ignorance, (2) color priority, (3) address priority, and (4) color mixing. These four are discussed below; Section 3.4 discusses other methods. Each con ict resolution mechanism is speci ed as a modi cation of step C of the color uni cation speci cation in Section 2.2. (a)

(b)

(c)

Figure 4: Common examples to illustrate con ict resolution mechanisms A set of common, simple examples is used for illustrating the behaviour of the dierent 26

mechanisms1 . The examples, shown in Figure 4, are all based on simple uni cation (the =/2 predicate) of two terms, where the initial tagging will result in a color con ict. (Note that in Figure 4(b), the entire rst instance of f(1) is tagged red, the functor f in the second instance is tagged green, and the second occurrence of the atom 1 is tagged blue.)

3.2.1 Ignore the Con ict

The simplest approach to dealing with color con ict is to ignore it where possible. Thus, for example, if two atoms which would otherwise unify are tagged with dierent colors, neither tag is changed. In the graphical display, then, both terms retain their color. The user can observe the con ict by noting a contrast between a band and a term it joins.

(a)

(b)

(c)

Figure 5: Examples of the con ict ignorance mechanism To illustrate, consider Figure 4(b). When the two instances of the constant 1 are uni ed, the tag of neither is changed (Figure 5(b)). However, if one term is a variable, then to be consistent with the semantics of the language, its tag is changed to that of the other term. This is illustrated in Figures 4(a) and 5(a) where the tag of the variable is changed when it is bound to atom 1. If both terms involved in the con ict are variables, a single tag must be determined since the variables are required to share as a result of the uni cation. The con ict resolution mechanism is therefore: C .1 If the two terms are atomic, the con ict is ignored. C .2 If both of the terms are variable, a single resultant tag is arbitrarily chosen from among the two, and both variables are given this tag. C .3 If one term is variable and the other is non-variable, the variable gets the non-variable term's tag. C .4 If both terms are functional terms, the con ict between the tags of the functors is ignored, as in case C .1 above. Resolution of any color con ict in the arguments of the two functional terms is handled by recursive application of the uni cation algorithm (and this con ict resolution mechanism). Figure 5 illustrates the eects of this scheme. (Each image shows the situation one step after the corresponding situation in Figure 4.) In addition, Figures 6(a) and 6(b) show \what happens next" for the situations in Figures 2(c) and 3(b), respectively. This scheme was the one used originally in Color Prolog [Dob+96]. 0

0

0

0

0

3.2.2 Color Priority

An alternative mechanism is to impose an (arbitrary) ordering on tag colors, and to resolve con icts by choosing the dominant color. This mechanism was implemented, with the ordering of colors no-color < red < green < blue. The con ict resolution mechanism is then straightforwardly speci ed as:

While the use of color is not strictly necessary to understand these simple examples (black-and-white and the outline of the color bands would suce), color becomes very important as the visualization becomes more complex | the typical situation. 1

27

(a)

(b)

Figure 6: Further examples to illustrate con ict ignorance mechanism (a)

(b)

(c)

Figure 7: Examples of the color priority mechanism C . Both terms are tagged with the more dominant color of the two. Figure 7 shows examples of this mechanism. Each image in the gure depicts the situation one step after the situation in the corresponding image in Figure 4. Figure 8 shows \what 0

(a)

(b)

Figure 8: Further examples to illustrate color priority mechanism happens next" for the examples of Section 3.1.

3.2.3 Address Priority

Another option is to choose one of the con icting tag colors over the other based on the addresses of the terms in the stack or heap. Obviously, the behavior becomes implementation dependent. For instance, a \higher" address may or may not correspond to an \older" term. Color Prolog implements two variants of this scheme: one uses the tag of the lower-addressed term to resolve con icts; in the other, the higher-address term. In general, this con ict resolution mechanism is speci ed as: C . Both terms are tagged with the color of the term with the lower (higher) address. Figure 9 shows examples of the higher-address variant. Each image gives the situation one step after the situation in the corresponding image in Figure 4. Further examples in Figure 10 show 0

28

(a)

(b)

(c)

Figure 9: Examples of the address priority mechanism

(a)

(b)

Figure 10: Further examples to illustrate address priority mechanism \what happens next" for the situations in Section 3.1.

3.2.4 Color Mixing

One might consider retaining a record of both colors contributing to a con ict when resolving it. One way to do this is to use a tag which, instead of being one color or the other, is a combination of both. For example, if a red constant is uni ed with the same constant tagged blue, the result is that both terms are tagged with a combination of red and blue, say magenta. Such a color mixing scheme can be made quite complex; e.g. a blue-green term uni ed with a violet term to yield one tagged pale blue. Color Prolog implements a restricted scheme which avoids such complexities, yet allows testing of this idea's feasibility. Only seven colors are used: the primary colors red, blue, green; direct combinations of two primary colors, namely yellow (from red and green), cyan (from green and blue), and magenta (from red and blue); and white (combination of all three primary colors). Table 1 speci es the operator for combining the colors. Note that even though all colors can be involved in mixing operations, the only possible red red red green yellow blue magenta yellow yellow magenta magenta cyan white white white

green blue yellow magenta cyan white yellow magenta yellow magenta white white green cyan yellow white cyan white cyan blue white magenta cyan white yellow white yellow white white white white magenta white magenta white white cyan cyan white white cyan white white white white white white white Table 1: Color mixing operation

colors for user tagging of a term (via the mouse) remain red, green, and blue. 29

(a)

(b)

(c)

Figure 11: Examples of the color mixing mechanism Figure 11 depicts the eects of this scheme, showing the situation one step after the corresponding situation in Figure 4. The grey background allows terms tagged white to be seen. The color bands in Figure 11(b) are yellow (from combining red and green) and magenta (from red and blue). In Figure 11(c) the resultant color is white. Further examples are given in Figure

(a)

(b)

Figure 12: Further examples to illustrate the color mixing mechanism 12 which show \what happens next" for the situations in Section 3.1.

3.3 Comparisons

The color priority and address priority schemes are subject to signi cant information loss. For example, in Figures 8 and 10 all evidence of one of the previous color tags is erased. On the other hand, some record is maintained with the other two schemes, as Figures 6 and 12 show.

(a)

(b)

(c)

Figure 13: Problems with color priority mechanism Another problem with the color priority scheme is that the pattern of resulting colors is dependent on the colors used. Figures 13(a) and 13(b) show the result of starting with same queries as in Figures 4(a) and 4(b), but exchanging the use of blue and red. The results are 30

Figure 14: Subdivision of connecting bands quite dierent than in Figures 7(a) and 7(b). The same change in tag colors yields the results in Figure 13(c) (as opposed to Figure 8(a)). Such behavior is not present with the other schemes. With con ict ignorance, for instance, a simple mapping of colors can explain the result of allocating colors dierently; similarly for the address priority scheme. The major shortcoming of the address priority scheme is that understanding resultant color patterns requires an understanding of the implementation, and of how terms are stored. This is not helpful to common users, and especially not to new learners. The color mixing scheme does not suer from the shortcomings of the other methods; i.e. no arbitrary choices are made, ordering of tagging does not matter, and some in uence of both initial colors is retained in the resultant tag. However, the main problem with this scheme is the user's own familiarity with the mixing of colors. How many users naturally recognize yellow as being the result of mixing red and green? It is suspected that most do not. Changing the primary colors of the color space (to cyan, magenta, and yellow) does not eliminate such problems. However, since only a small number of color combinations are allowed, it is reasonable that users could learn to recognize the meaning of the color combinations. We hope to test this empirically in future.

3.4 Other Methods

When a con ict occurs, instead of having to choose a single color for the two unifying terms, the visualization system could instead retain a record of both colors, and alternately display them. That is, the colored area around the two terms and the connecting color band would cyclically alternate between the two colors. While scalable, this scheme may result in visual confusion for the user, especially if the computation is large with many color con icts and a great deal of changing-color activity on the screen. Another method proposed is to subdivide the color connecting bands between tagged terms when a con ict occurs, and have subdivisions (sub-bands) retain the con icting colors. Figure 14 gives an example. Since there are three possible tag colors, each connecting band could be divided into at most three sub-bands. This scheme may work for simple traces, but for executions of \normal" complexity, the user may lose track of the meaning of a multitude of color bands and sub-bands. Another technique is a modi ed form of con ict ignorance: ignore the con ict but highlight the point where it occurs with a dierent, highlight color. This eliminates the information loss problem, yet provides meaningful information by alerting the user to the point of a color con ict.

4 Conclusions and Future Work The rst version of Color Prolog used the con ict ignorance scheme because it was simple. The other schemes, while more complex, do not seem to have signi cant advantages over it, with the possible exception of color mixing. However, this latter scheme has the problem, as yet untested, that the user may not quickly comprehend the meaning of various colors (i.e. that a particular color is a mixture of the primaries, and what those primaries are). The characteristics of the various con ict resolution mechanisms may be advantageous or detrimental, depending on the situation at hand. It thus seems appropriate to enable the 31

user to dynamically select the mechanism used. The present implementation employs a static, command-line setting, but it would not be hard to have a more user-friendly, dynamic mechanism (menu, buttons, etc.). However, altering the con ict resolution mechanism on-the- y could not change the result of uni cations already made, only the result of subsequent ones. We hope to be able to test Color Prolog, with many of the modi cations mentioned herein, this fall in the classroom.

References [Boja89] [Byrd80] [DeCl86] [Dob+96]

[ECRC96] [EiBr88] [MaWa88] [Neu+97] [Neum90] [SICS96]

D. Bojantchev, \XPGT User's Guide", Computer Science and Engineering Department, Case Western Reserve University, Cleveland, Ohio, 1989. L. Byrd, \Understanding the Control Flow of PROLOG Programs", Proceedings of the Logic Programming Workshop, edited by S.- A. Tarnlund, pp. 127{138, 1980. A. D. Dewar and J. G. Cleary, \Graphical display of complex information within a Prolog debugger", in International Journal of Man-Machine Studies, Vol. 25, 1986, pp. 503{521. M. Dobrohoczki, A. Kusalik, and E. Neufeld, \Colour Tagging for Prolog Visualization", in Proceedings of the Poster Session at JICSLP'96, Norbert E. Fuchs and Ulrich Geske, editors, GMD-Studien Nr. 296, Bonn, Germany, September 2-6, 1996, pp. 253{269. European Computer-Industry Research Centre (ECRC), \ECLiPSe User Manual", Version 3.5, December 1995. Available at \http://www.ecrc.de/research/projects/eclipse/". M. Eisenstadt and M. Brayshaw, \The Transparent Prolog Machine (TPM): An execution model and graphical debugger for logic programming", in Journal of Logic Programming, Vol. 5, No. 4, 1988, pp. 277{342. D. Maier and D. S. Warren, Computing with Logic: logic programming with Prolog, Benjamin/Cummings, 1988. E. Neufeld, A. J. Kusalik, and M. Dobrohoczki, \Visual Metaphors for Understanding Logic Program Execution", in Graphics Interface '97, Kelowna, B. C., Canada, May 1997, pp. 114{120. U. Neumerkel, \Extensible uni cation by metastructures" in Proceedings of META-90, Leuven, Belgium, April 1990, pp. 352{364. Swedish Institute of Computer Science (SICS), \SICStus Prolog User's Manual", Release 3 #5, Kista, Sweden, October 1996. Available at \http://www.sics.se/isl/sicstus.html#Manuals".

32