Behavior Combination Through Analogy
Braden Craig
Department of Computer Science
and Institute of Cognitive Science
University of Colorado at Boulder
bradensc@triad.rr.com
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.
The system I have created generates code according to analogies by performing role-based
substitutions between agents within the programming environment
of Agentsheets. VisualAgentalk (VAT) 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 VAT
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 as 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)
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 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. 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 using graphical rewrite rules
instead of VisualAgentTalk. Special "Thanks" also go out to
Prof. Clayton Lewis for his continued and insightful discussions,
critiques, and support.
Home | Resume