Proposal of the initial state
=============================

When a new problem space is selected for a goal, an initial state must be
proposed and selected.  The initial state can be an existing state in the
goal hierarchy, in which case, an acceptable (or require) preference should
be used to select it.  If a new state is to be created, an acceptable (or
require) preference should be created and the rest of the structure added on
during elaboration.

For subgoals that are applying an operator, the initial state is usually
either the same as the superstate (the state to which the operator was being
applied), or it is a new state with a pointer back to the superstate.  Below
is an example for the Blocks World where the same state is used.

(sp blocks-world*propose*initial*state
    (goal <g> ^name build-tower ^problem-space <p> ^object <sg>)
    (<p> ^name blocks-world)
    (goal <sg> ^state <ss>)
    -->
    (<g> ^state <ss>))


If the operators in the subgoal create augmentations of the state that are
local to the subgoal, then it is best to have a new state symbol with a
pointer back to the superstate.  All access to the relevant data on the
superstate is indirect through this pointer; however, when the subgoal
terminates, all of the temporary data is automatically removed.  For many
tasks, the state in the top context is important because it is the locus for
all input and output.  As a convention, the attribute ^superstate is
used for superstates and ^io-state is used for the top state in which
all input and output is performed.
 For example, in
the Blocks World, the following production would be appropriate if the
operators in the subgoal created temporary structures.

(sp blocks-world*propose*initial*state
    (goal <g> ^name build-tower ^problem-space <p> ^object <sg>)
    (<p> ^name blocks-world)
    (goal <sg> ^state <ss>)
    (<ss> ^io-state <ios>)
    -->
    (<g> ^state <s>)
    (<s> ^superstate <ss> ^io-state <ios>))

However, we will use the first one because we do not need any local
structure.  Using d, we can fire that production and select the state.

Soar> d 1

     6:       S: S1 (top-state)

To see the substructure of the state after it is selected, we can use {print} with a keyword argument that specifies how many levels of
augmentations to print out.  The default is 1, which shows just the
augmentations of the object that is the argument to print.  By using 2,
we can print the augmentations of S1 as well as one level of
substructure:

Soar> print :depth 2 s1
(S1 ^text-environment E1 ^object-dynamic T1 ^object-dynamic B1
       ^object-dynamic B2 ^object-dynamic B3 ^io-state S1 ^name top-state)
  (E1 ^text-output-stream *standard-output*
         ^text-input-stream *standard-input*)
  (T1 ^clear yes ^object-static T2)
  (B1 ^object-static B4 ^clear yes ^ontop B5)
  (B2 ^object-static B5 ^clear no ^ontop T2)
  (B3 ^object-static B6 ^clear yes ^ontop T2)