Behavior Combination Through Analogy

Braden Craig

Department of Computer Science and Institute of Cognitive Science
University of Colorado at Boulder
moc.againgiaagainrcagainnedarbagain@nedagainarbandagain
Link to poster on IEEE site

Abstract

Although people can readily use and generate analogies in everyday discourse to relate disparate domains, even most of today's end-user programming languages provide no support for creating analogies. Finding ways to represent analogies that allow users to express relations between code fragments via analogy is challenging. Within Agentsheets a "programming by analogy" (PBA) mechanism has been developed that allows end-users to reuse code between acting agents by creating analogies between them. This mechanism harnesses the intuitive power of analogy to generate and reuse code in a way that hides complicated inheritance issues from end-user programmers.

1: Overview

This paper presents a new mechanism that allows users to create analogies between similarly behaving agents in order to promote code reuse within the visual programming environment of Agentsheets. First, motivation for the current research is presented. An extremely brief introduction to Agentsheets immediately follows. Next, the newly created "programming by analogy" (PBA) mechanism is described. Its ability to promote code reuse without exposing end-user programmers to complicated inheritance issues is discussed. Possible future enhancements to the current mechanism are then proposed, and conclusions about the present mechanism's usefulness for end-user programming are drawn.

1.1: Introduction/Motivation

Many studies have been undertaken to uncover how humans understand analogy. A large interest in this field has developed, and many researchers argue that instead of being a peripheral way of processing information, analogy and metaphor are central to the way we understand language and the world in general [4], [6], [8]. In fact, in situations most foreign to us, an analogy or metaphor often provides clarity by relating unfamiliar domains of inquiry to domains with which we are familiar. With these considerations in mind it makes sense to attempt to harness the expressive power of analogies in end-user programming languages. In doing so, one bridges the gap between the kinds of expressions used to express ideas in natural language and the kinds of expressions used to generate computational constructs in programming languages.

2: Agentsheets

The system I have created generates code according to analogies by performing role-based substitutions between agents within the programming environment of Agentsheets with VisualAgenTalk (AS-VAT). VisualAgenTalk is a visual, rule-based programming language within Agentsheets that allows users to program the behavior of agents that interact in grid-based worksheets. (In fact, the current analogy mechanism evolved from an earlier analogy mechanism that was created within Agentsheets before the extension of VisualAgenTalk was added [13].) In general, Agentsheets is an agent-based, spreadsheet-based, visual programming environment that allows a range of end-users to create SimCityTM-like interactive simulations [12], [14].

3: Programming By Analogy (PBA)

Figure 1 shows the new PBA mechanism being used to create an analogy between an aquaplane and a regular plane. One should read the analogy from top to bottom as follows:

"An aquaplane behaves toward the sky like a regular-plane behaves toward the sky."

From top to bottom the agents depicted in the various icon-windows of the analogy-window will be referred to as follows:

First icon-window -----> Target-agent (e.g. "Aquaplane")
Second icon-window --> New-Behavior-Receiver (NBR, e.g. "Sky")
Third icon-window ----> Source-agent (e.g. "Regular- Plane")
Fourth icon-window ---> Original-Behavior-Receiver (OBR, e.g "Sky").


Figure 1: The PBA mechanism showing the analogy "An aquaplane behaves toward the sky like a regular-plane behaves toward the sky." (old depictions)

In this case, an analogy is being made about "flying" by referring to the way a regular-plane behaves toward the sky. In processing this particular analogy, the new "programming by analogy" (PBA) mechanism checks the conditions of the rules of the source-agent, the regular-plane, to see if any of them refer to sky-agents. If a condition is found in a regular-plane rule that refers to a sky-agent the entire rule is "carried-over" or mapped into the rule-editor of the aquaplane.

Figure 2 shows a hypothetical rule of a regular-plane (top) to be mapped into a rule of the aquaplane (bottom).



Figure 2: Applying the analogy in Figure 1 to the top rule generates the bottom rule shown here. (new depictions)
The top rule reads: "If I see myself as a right-facing regular-plane and I see sky to my left, then change myself to a left-facing regular-plane and move to the left."
The bottom rule reads: "If I see myself as a right-facing aquaplane and I see sky to my left, then change myself to a left-facing aquaplane and move to the left."

Notice that the top rule refers to a sky-agent in its conditions. In accordance with the analogy in Figure 1, the current PBA mechanism maps this rule into the aquaplane's rule-editor. Such a mapping results in the bottom rule shown.

In mapping this rule from source-agent (regular-plane) to target-agent (aquaplane) a number of substitutions are made. First, the target-agent is substituted for all occurrences of the source-agent. But notice also that the left-facing regular-plane, corresponding to a regular-plane flying "to the left," is also correctly mapped to a left-facing depiction of an aquaplane.

These different depictions of agents are related via family-relations. Such relations are depicted in Figure 3 by gray arrows connecting "root-agents" to their "family-members."


Figure 3: AS-VAT gallery with family relations. (old depictions)

The arrows represent dependency relations between a root-agent and its family-members. That a set of family-members is dependent on a root-agent reflects the creational/derivational history of these agents. In this particular example the left-facing depictions of the plane, aquaplane, and boat were made by cloning the right-facing depictions of each with a "Flip-Horizontal" transformation specified. Keeping derivational histories of graphical objects has also proven helpful in other end-user programming efforts. Namely, many attempts at providing mechanisms that allow users to "program by demonstration" have utilized such histories [7], [9], [11].

With respect to the current mechanism, such a derivational history allows for a type of role-based substitution involving families of icons instead of just unrelated instances of icons. When the PBA mechanism copies new rules into the target-agent's rule-editor it substitutes for the target-agent and for the NBR according to family-relations between source-agent and OBR agent-depictions referred to in the source-agent's rule-editor. This role-based substitution is similar to what Lewis calls "pupstitution" [10]. Pupstitution is a term coined from the role-based substitutions generated by John Anderson's PUPS-based (Penultimate Production System) model of analogy [1], [2].

The current PBA mechanism performs pupstitutions by substituting according to the role of "family-member" that family-depictions of the source-agent and the OBR play in a rule. Family relations between agent-depictions of a given agent provide weak syntactic and semantic clues about the "role" a given depiction of an agent might play within rules in which it resides. As well, if a corresponding family-member for the target-agent or the NBR of an analogy does not yet exist, a new family-member is created by the proposed PBA mechanism. New family-members are created using the same transformations that were used to create the family-members of the source-agent or the OBR for the analogy in which the given pupstitution is being made.

3.1: PBA Mechanism: Multiple Rules

In dealing with multiple rules a few new issues arise. By default, rules owned by AS-VAT agents are placed in a "While Running" method. As rules are pupstituted from a source-agent to a target-agent, they are placed in a method of the same name as that from which they are generated. For example, following the analogy of Figure 1, if a set of rules from a plane-agent is pupstituted from its "While running" method, these pupstituted rules will be placed in the "While running" method of the aquaplane. Had the original rules been located in a "Flying" method of the plane, the pupstituted rules would have been placed in a "Flying" method of the aquaplane. If analogies are made with a target-agent that already owns the relevant methods into which rules are to be pupstituted, newly pupstituted rules are appended to the end of the list of existing rules for each matching method of the target-agent. Otherwise, the appropriate methods are generated in the target-agent by the PBA mechanism, and pupstituted rules are placed there. As well, if a new method is generated in a target-agent, a call to that method is automatically pupsituted from its source-agent. This is done by pupstituting all those rules whose actions contain a call to the said method. Conversely, if a pupstituted list of actions contains a call to an unowned method, this method is automatically pupstituted, in its entirety, from the source-agent to the target-agent by the proposed PBA mechanism.

4: Inheritance and the PBA Mechanism

The current analogy mechanism addresses complicated inheritance issues by allowing users to create multiple analogies. (See Snyder [15] and Ducernau [3] for extended discussions of topics surrounding multiple and single inheritance.) For example, a user can create behavior for an aquaplane by using the following analogies:

"An aquaplane behaves toward the sky like a regular- plane behaves toward the sky."
"An aquaplane behaves toward water like a boat behaves toward water."

The PBA mechanism handles multiple analogies in the same way that it handles single analogies. (i.e. It splices in rules, adds methods, etc. as described for single uses of the PBA mechanism.) The only difference here is that the rules generated by each use of the PBA mechanism must be saved before executing another analogy for a given agent. Figure 4 shows a rule-editor for an aquaplane generated by using the PBA mechanism twice to execute the above analogies.


Figure 4 shows rules generated from a plane whose behavior was located in "While running" and "fly" methods
and from a boat whose behavior was located in "While running" and "navigate" methods. (new depictions)

Multiple inheritance is never invoked to allow the sharing of rules between related agents. Instead, multiple analogies are created and spliced together to provide such sharing. Thus, the current PBA mechanism provides a way of reusing code from multiple agents that does not expose end-users to complicated issues surrounding multiple inheritance. Users are only exposed to intuitive analogy-making processes, that allow them to program-in-the-language-of-the-user-interface, providing a natural bridge to some of the central ideas of the object-oriented paradigm. (See [5], [7], [9], and [11] for examples of other systems that allow users to program-in-the-language-of-the-user-interface.)

5: Future Enhancements

One can readily think of approaches that enhance the "splicing approach" currently used to build complex analogies within the Agentsheets programming environment. For example, more sophisticated "tagging" approaches might create more complete "histories-of-use" and "histories-of-creation" for agents. Such new approaches would provide more complete semantic and syntactic clues about the "role" agents play in given rules. This would in turn aid in the "pupstitution" capabilities of a new Agentsheets PBA mechanism. As well, analogies could be performed according to methods that a given agent owns. (e.g. An aquaplane "Flies" like a plane "Flies.") Such extensions are left for future work on the topic.

6: Conclusions

The proposed analogy mechanism in AS-VAT gives users a new way to share code between similarly behaving agents. Because AS-VAT's features allow users to program-in-the-language-of-the-user-interface, such a mechanism can be represented in an intuitive way that promotes end-user programming. By supporting a primitive splicing approach, the current "programming by analogy" mechanism allows users to share code between multiple source-agents and a target-agent. Such reuse of code is often associated with complicated multiple inheritance hierarchies in other programming languages/environments. The current PBA mechanism provides end-users with a way of reusing code between multiple agents that encourages the basic OO design practice of providing methods for objects/agents while hiding from them many more complicated concepts surrounding inheritance. Finally, the current PBA mechanism employs elements of John Anderson's PUPS-based theory of analogy. By performing pupstitutions according to family-relations this PBA mechanism makes mappings between source-agents and target-agents coherent and intuitive. Hopefully, such functionality will entice users to use the PBA mechanism to share code between agents in Agentsheets. This mechanism can be seen as a small step toward exploiting new understandings of metaphorical and analogical reasoning within iconic end-user programming environments.

References

  1. Anderson, J. R., & Thompson, R. (1989). Use of analogy in a production system architecture. In S. Vosniadou & A. Ortony (Eds.), Similarity and Analogical Reasoning (pp. 267-297). Cambridge: Cambridge University Press.
  2. Anderson, J.R. (1993). Rules of the Mind. Hillsdale, NJ: Erlbaum.
  3. Ducernau, R.; Habib, M.; Huchard, M.; Mugnier, M.L. (1994). Proposal for a Monotonic Inheritance Linearization. OOPSLA '94, 164-175.
  4. Gentner, D. (1983). Structure Mapping: A theoretical framework for analogy. Cognitive Science, 7, 155-170.
  5. Halbert, D.C. (1993). Smallstar: Programming by Demonstration in the Desktop Metaphor. In A. Cypher (Ed.), Watch What I Do: Programming by Demonstration (pp. 102-123). Cambridge, MA: MIT Press.
  6. Hofstadter, D. (1995). Fluid Concepts and Creative Analogies. NY: HaperCollins Publishers, Inc.
  7. Kurlander, D. (1993). Chimera: Example-Based Graphical Editing. In A. Cypher (Ed.),Watch What I Do: Programming by Demonstration (pp.270-290). Cambridge, MA: MIT Press.
  8. Lakoff, G. (1987). Women, Fire, and Dangerous Things. Chicago: University of Chicago Press.
  9. Leiberman, H. (1993). Mondrian: A Teachable Graphical Editor. In A. Cypher (Ed.), Watch What I Do: Programming by Demonstration (pp. 340-358). Cambridge, MA: MIT Press.
  10. Lewis, C. H. (1988). Why and How to Learn Why: Analysis-based Generalization of Procedures. Cognitive Science, 12, 211-256.
  11. Potter, R. (1993). Triggers: Guiding Automation with Pixels to Achieve Data Access. In A. Cypher (Ed.), Watch What I Do: Programming by Demonstration (pp. 360-380). Cambridge, MA: MIT Press.
  12. Repenning, A. (1993). Unpublished PhD Dissertation. Agentsheets: a Tool for Building Domain-Oriented Dynamic, Visual Environments University of Colorado at Boulder, Dept. of Computer Science.
  13. Repenning, A. (1995). Bending the Rules: Steps Toward Semantically Enriched Graphical Rewrite Rules. in Proceedings of Visual Languages, Darmstadt, Germany, 1995.
  14. Repenning, A., (1995). Agentsheets: A Medium for Creating Domain-Oriented Visual Languages. Computer , March 1995, 17-25.
  15. Snyder, A. (1987). Inheritance and the Development of Encapsulated Software Components. In B. Shriver & P. Wegner (Eds.), Research Directions In Object-Oriented Programming (pp. 165-188). Cambridge, MA: MIT Press.

Acknowledgments

Special "Thanks" go to Prof. Alex Repenning for creating Agentsheets and for extensively discussing this paper with me. Special "Thanks" go out to Corrina Perrone upon whose work I expanded. Corrina originally added a PBA mechanism to a version of Agentsheets in which end-users programmed using graphical rewrite rules instead of VisualAgenTalk. Special "Thanks" also go out to Prof. Clayton Lewis for his continued and insightful discussions, critiques, and support.

Home | Résumé