Like Soar8.2, the TinySoar host enviornment is a Tcl extension that provides a command-line interface to the TinySoar runtime. The Tcl extension also includes commands useful for developing and debugging agents for the runtime.
The handful of commands that the TinySoar Tcl extension adds to the Tcl environment are listed below.
preferencescommand has three forms. The first form displays the preferences for the specified slot:
<id>must be an identifier,
<attr>must by a symbolic constant. The second form is used to add a preference to the specified slot:
<id>must be an identifier,
<attr>must be a symbolic constant, and
<val>may be an identifier, a symbolic constant, or a numeric constant. Numeric constants must be prefixed by a
-to distinguish them from identifiers.
<type>is the preference type; specifically:
| ||indifferent, unary or binary|
| ||worst if unary, worse if binary|
| ||best if unary, better if binary|
<ref>to be specified. The referent may be an identifier, a symbolic constant, or a numeric constant. The result of
preferences -ais a unique number identifying the preference. This value can be used with the third form of the command,
preferences -r, to remove the preference from working memory. Note that
preferences -ris not idempotent: using it more than once on the same preference (or using it with a value not returned from
preferences -a) will cause undefined behavior and possibly crash the runtime.
Below is a sample session that illustrates how some of the commands
are used. To follow along, start
tclsh in the
directory where you've built
tinysoar.so, and load the
$ TCLLIBPATH=`pwd` tclsh % source ../tinysoar/tests/drive.soar Firing: Retracting: compiled: propose*drive compiled: implement*drive compiled: drive*reconsider %
Run two elaboration cycles.
% ela Firing: propose*drive Retracting: % ela :  Firing: implement*drive drive*reconsider Retracting: %
Note the `
: ' that is printed after the second
elaboration. This indicates that operator
 has been
selected for state
Let's print the working memory elements currently associated with
. (Note that the top-level state is
% print 1 ( ^superstate nil ^io  ^operator  ^operator  +) %
In other words, the top state has the I/O link
 both with “normal”
^operator ) and “acceptable”
^operator  +) working memory elements
Let's look at the operator a bit more closely:
% print 5 ( ^name drive) %
's name is
Let's look at what preferences are currently in working memory for
% pref 1 ^operator 134698720:  @ 134691928:  + %
There is a reconsider preference (`
@') and an
acceptable preference (`
+') for the
^operator slot in the top state. Both preferences are
Now let's tinker with preferences a bit:
% print 2 ( ^input-link  ^output-link ) % pref -a 3 ^sensor-1 +100 + 134699296 %
We just added an acceptable preference to the input link, setting
^sensor-1 attribute to a numeric constant of
+100. Let's double-check to be sure:
% pref 3 ^sensor-1 134699296: 100 + %
Note that there are no square-braces around the
that indicates that the value `100' is a numeric constant,
not an identifier.
Has a working memory element been created, too?
% print 3 () %
No! The preference is present, but no working memory element has been created yet. Working memory elements get created during elaboration as a result of preference addition. So, after elaborating once, we should see our acceptable preference converted into a working memory element:
% ela :  Firing: implement*drive drive*reconsider Retracting: implement*drive drive*reconsider % print 3 ( ^sensor-1 100) %
Now let's remove that preference, and verify that it's gone:
% pref -r 134699296 % pref 3 ^sensor-1 %
The preference is gone; does the working memory element remain?
% print 3 ( ^sensor-1 100) %
Yes. Again, working memory elements are created and destroyed during elaboration:
% ela :  Firing: implement*drive drive*reconsider Retracting: implement*drive drive*reconsider % print 3 () %
At this point, the agent's input-link is in the same state as it was before we began tinkering with preferences.