Initializing Soar to run a task
-------------------------------

In order for the system to work on the Blocks World problem, there must be a
goal in working memory to solve the problem.  The goal to solve the Blocks
World could be arise in one of two possible ways.

  1. The Blocks World is the only task that the system can perform.  The top
     goal in working memory then becomes the goal of the task.  In this case,
     the problem can be initialized by a production added by the user to
     augment the top goal.  One production tests for (goal <g> ^object nil)
     and augments the goal with the appropriate desired state.  Additional
     productions then propose the initial problem space and state.  Below is
     an example of the first production for the Blocks World.
     
               (sp top-goal*elaborate*goal*solve-blocks-world
                 (goal <g> ^object nil)
               -->
                 (<g> ^desired <d> ^name solve-blocks-world)
                 (<d> ....))
     
     
  2. There are many tasks that the system can work on and stacking blocks is
     but one.  In this case, there must be an operator that represents the
     task of stacking blocks.  This operator is proposed and once selected, a
     no-change impasse arises along with an associated subgoal in which the
     task is performed.

The second option is more general and preferred because it allows the system
to work on many different tasks.  For the remainder of this chapter, we
assume the second option, that is, the task of stacking blocks arises as an
operator in some supergoal.

In general, the initial state of a top-level task is defined by input from an
environment.  Unfortunately, this requires writing the input and output
functions that support interaction with a real Blocks World as well as a
simulator for that world.  In this example, we will assume that the system
recalls the initial state from its long-term production memory.  Although
this assumption restricts the system to attempting problems that start with
this state, other initial states can be used by simply changing the
production that recalls the initial state.  The problem we will work on is
the same one as used in Chapters See The Problem Space Level and 
See Semantics of the Symbol Level, and as shown in Figure ? on page ? with an
initial state in which block A is on block B, and blocks B and C are on the
table.  The goal is to create a tower with A on B, B on C, and C on the
table.

Once the initial state is selected, it will be modified by internal actions
instead of reflecting the perception of changes to an external environment.
The production to augment the initial state is as follows:

(sp top-goal*elaborate*initial-state
  (goal <g> ^name top-goal ^problem-space.name top-ps ^state <s>)
  (<s> ^name top-state)
  -->
  (<s> ^object-dynamic <table-dyn> + &,
                      <blockA-dyn> + &, 
                      <blockB-dyn> + &, 
                      <blockC-dyn> + &)
  (<blockA-dyn> ^ontop <blockB> ^clear yes ^object-static <blockA>)
  (<blockA> ^name A ^type block)
  (<blockB-dyn> ^ontop <table>  ^clear no ^object-static <blockB>)
  (<blockB> ^name B ^type block)
  (<blockC-dyn> ^ontop <table> ^clear yes ^object-static <blockC>)
  (<blockC> ^name C ^type block)
  (<table-dyn> ^object-static <table> ^clear yes)
  (<table> ^name table ^type table)
  (write (crlf) |Initial state has A on B and B and C on the table.|))

Notice that all of the ^object-dynamic augmentations of the state are
multi-valued attributes and thus have parallel preferences for each of the
values.  The assumption in Soar is that only a single value is allowed for an
augmentation.  If there is more than one value that can be selected, an
attribute impasse will arise, unless parallel preferences are used.

The write action at the end of the production provides a simple method for
printing comments during a run.  In general, I/O should be used, but for
simple tracing, write is sufficient.

Production top-goal*elaborate*initial-state matches the current contents of
working memory and will fire on the next elaboration cycle.  The user can
query Soar to determine which productions have new instantiations waiting to
fire by using the (ms) function (see Section See ms on page See ms).

Assertions:
  top-ps*elaborate*initial-state 
  default*top-ps*propose*operator*wait 
Retractions:

The results of this function show that there are two productions ready to
fire.  One of these, top-goal*elaborate*initial-state, we expected, but there
is a second default production ready to fire, called
default*propose*operator*wait.  We can print out this production using the
function print which prints out productions and working memory objects (see
Section See print on page See print).

Soar> p default*top-ps*propose*operator*wait 
(sp default*top-ps*propose*operator*wait
  "Propose operator wait whenever in problem space top-ps."
  (goal <g> ^problem-space <p> ^state <s>)
  (<p> ^name top-ps)
-->
  (<g> ^operator <o> + ^operator <o> <)
  (<o> ^name wait +))

This production creates the wait operator with an acceptable and worst
preference (see Section See The top context on page *Note The top
context::).  The wait operator will be selected when no other operator is
acceptable for the top problem space.  Thus, when there is nothing else for
the system to do, it will wait.

If we continued the run at the default level of trace, there would be no
indication of specific production firings; only context decisions will be
traced.  To change the trace level, the function (watch) is called (see
Section See watch on page See watch). The default level of trace is 0
and it prints out only the selections of goals, problem spaces, states, and
operators.  To see changes to working memory, watch level 2 is necessary.  To
run only a single production firing cycle, (run 1) is used (see Section 
See run on page See run).

Soar> watch 2

Soar> run 1

--- Input Phase ---
=>WM: (14: E1 ^text-output-stream *standard-output*)
=>WM: (13: E1 ^text-input-stream *standard-input*)
=>WM: (12: S1 ^text-environment E1)
--- Preference Phase ---
Firing top-ps*elaborate*initial-state 
         (3:  G1 ^name top-goal) (11: G1 ^state S1) (9: S1 ^name top-state) 
         (7: G1 ^problem-space P1) (5: P1 ^name top-ps)
Initial state has A on B and B and C on the table.
Firing default*top-ps*propose*operator*wait 
         (7: G1 ^problem-space P1) (5: P1 ^name top-ps) (11: G1 ^state S1)
--- Working Memory Phase ---
=>WM: (39: G1 ^operator O1 +)
=>WM: (38: O1 ^name wait)
=>WM: (37: T2 ^type table)
=>WM: (36: T2 ^name table)
=>WM: (35: T1 ^object-static T2)
=>WM: (34: T1 ^clear yes)
=>WM: (33: B6 ^type block)
=>WM: (32: B6 ^name c)
=>WM: (31: B3 ^ontop T2)
=>WM: (30: B3 ^clear yes)
=>WM: (29: B3 ^object-static B6)
=>WM: (28: B5 ^type block)
=>WM: (27: B5 ^name b)
=>WM: (26: B2 ^ontop T2)
=>WM: (25: B2 ^clear no)
=>WM: (24: B2 ^object-static B5)
=>WM: (23: B4 ^type block)
=>WM: (22: B4 ^name a)
=>WM: (21: B1 ^ontop B5)
=>WM: (20: B1 ^clear yes)
=>WM: (19: B1 ^object-static B4)
=>WM: (18: S1 ^object-dynamic T1)
=>WM: (17: S1 ^object-dynamic B1)
=>WM: (16: S1 ^object-dynamic B2)
=>WM: (15: S1 ^object-dynamic B3)
--- Output Phase ---

During the preference phase, the productions fire, creating their preferences
and executing any actions, such as write which prints out "Initial state has
A on B and B and C on the table." in this trace.

The creation of the preferences does not show up during a watch 2 trace, only
in a watch 3 trace.  The name of the production is followed by the the
working memory elements that matched the conditions of the production.  The
working memory elements include their *time-tags*, which are unique and can
be used to refer to the working memory elements in the future. For example,
the working memory element (G1 ^name top-goal) has time tage 3.

During the working memory phase, all of the changes are made to working
memory. Additions are denoted by =>, while removals are denoted by {<=}.  In
this case, no working memory elements are removed, and working memory
elements with time-tags 15--39 are created.  Time-tags are used by other user
interface functions, such as matches.  They can be used to print out an
individual working memory element by using (wm) (see Section See print on
page See print) and print.

Soar> wm 16
(16: S1 ^object-dynamic B2)