Elimination of impasses
-----------------------

A context impasse can be eliminated by changing the preferences available for
the context slot or by changing a higher-level decision in the context stack.
Whenever there is a change in the preferences that are available for a
context slot with an impasse, the architecture attempts to make a decision on
that slot during the next decision following quiescence; if the impasse has
been resolved, the subgoal is terminated.  For example, if a tie impasse
arises for a context slot, it will terminate when sufficient preferences have
been created so that a single object dominates all others, or all objects are
mutually indifferent.

Any context impasse can also be eliminated by changing a decision higher in
the context stack.  A change higher in the context stack leads to the removal
of all preferences for the lower-level identifier and attribute.  The change
can be either selecting a different object for a higher slot or resolving a
higher impasse.  An example of this is rejecting the problem space when there
is a constraint-failure impasse for the state or operator.

Resolving an attribute impasse is trickier because no *justifications* (see
Section See Subgoal results on page See Subgoal results) are built to
maintain the preferences that resolve the impasse.  Justifications cannot be
built because the cause of an attribute impasse---multiple alternative values
for an attribute---is not represented in working memory.  The acceptable
preferences for non-context augmentations are held only in preference memory,
making impossible to create a justification (or chunk) to support the result.
Therefore, an attribute impasse must be resolved by an O-supported preference
so that the preference persists after the impasse object is removed.  If the
preference has only I-support, it will be retracted as soon as the impasse is
resolved because the production that created it depends on the existence of
the impasse.  The impasse will then be recreated, leading to an infinite
loop.

Below are four approaches to eliminating an attribute impasse:

  1. If the impasse arises in the middle of an operator application, include
     in the operator application productions some that detect and eliminate
     attribute impasses.  As part of an operator, these productions create
     O-supported preferences which will be persistent.
     
     
  2. If the impasse arises in the middle of an operator application, and the
     impasse prevents the operator from terminating, use the resulting
     subgoal (arising from an operator no-change impasse) to apply operators
     that detect and resolve the attribute impasse (and, indirectly, the
     operator no-change).  An attribute impasse can prevent termination if
     the attribute involved is tested by the production that generates the
     reconsider.  The result of fixing the impasse in the subgoal is a chunk
     that behaves like the special productions do in approach (1), above.
     
  3. When an attribute impasse arises, create an operator to handle the
     impasse and prefer it to all others.  One general strategy is to use
     approach (2) above for attribute impasses that lead to an operator
     no-change, and to use the current approach for attribute impasses that
     lead to operator ties or conflicts.
     
  4. If the attribute impasse does not lead to another impasse (such as an
     operator tie or no-change), then ignore it until it causes problems.
     This "lazy evaluation" approach has a problem in that the existence of
     the attribute impasse could cause different productions to fire than
     would otherwise, leading to different results in problem solving.

Both context and attribute impasses can also be resolved by the retraction of
existing preferences. For example, productions can change the substructure of
an object that provides I-support to a preference, via an instantiation.  For
example, if an instantiation creates a preference that causes an impasse, the
objects matched by that instantiation can be altered, causing the
instantiation to retract and possibly resolving the impasse.  However, there
is no representation in working memory of the objects that provide I-support
for a preference, so it is not possible to determine directly which object to
modify to resolve an impasse this way. Trial and error may be the only
approach.