Operator subgoaling
===================

If an operator has been selected but cannot be applied to the current state,
a useful strategy is to create a subgoal to find a state where the operator
can be applied.  This strategy is called *operator subgoaling* (also
{precondition satisfaction}) and is a common AI technique dating back to GPS.
In Soar, operator subgoaling is appropriate when an operator has been
selected and a no-change impasse arises.  This is implemented by recreating
the same context in the subgoal, but with the desired state being the the
operator that is to be applied.

To recreate the same context, acceptable and worst preferences are created to
select the operator's problem space in the subgoal.  If no other problem
spaces are suggested, the problem space will be selected, allowing a search
to be performed in the same problem space as the supergoal, but with a new
goal, that of applying the supergoal's operator.  The presumption is that the
selected operator could not apply to the current state, so another state must
be found.

Once the super problem space has been selected, the goal is named
{operator-subgoal} and augmented with the superoperator as its {^desired}.
This establishes a convention that when the desired augmentation of a goal is
an operator, then the object of the goal is to achieve a state in which the
operator can be applied.  Within the subgoal, the superoperator will not be
selected, since it is known that the operator will not apply to it.  If the
state ever changes so that the operator can apply, it will apply by having
productions fire in the supercontext that modify the state and then
reconsider it.  Thus, the termination of operator subgoaling is done
automatically by applying it in the supercontext.