The NL "Top" Space in Integrated Task/NL Systems

Unfortunately, not all Soar systems are written in this fashion. In particular, some use the "Michigan" style, in which high-level goals and deep goal stacks can persist for long periods. In such systems, kicking out the top task operator to let NL-Soar have the top operator slot would destroy a lot of task state, much of which might not be recoverable. Even if it were recoverable, the task system will not have the necessary productions to do so, because NL-Soar could return control to the task in a situation not anticipated in the task's top-level productions.

The solution we have adopted is to allow NL-Soar to "pretend" that any appropriate problem space is really the top space, so that its top-level operators can fire there. Doing this required two modifications to NL-Soar:

1. Top-level NL-Soar operators can be proposed in any state marked with a (^language-ops-allowed yes) attribute. This gives some flexibility to the task/NL interaction. For example, if only the top state has this flag, then we get a neo-PEACTIDM style NL-Soar. If only the bottom state gets the flag, then NL-Soar will fit cleanly into a "Michigan" style system, because it will not interfere with the task's goal stack. Other, more conditional, arrangements allow for more specific control of when task and NL operations can take place.

2. Every state marked with (^l-o-a yes) must also have a ^top-state attribute that points to the top state. This allows NL-Soar operators to have access to a single state for partial results even if they fire in different task spaces (as they may). Note that one consequence of this is that chunks built when NL-Soar is using the actual top state will be different than ones when NL-Soar operators fire in task sub-spaces, because in the former case the ^state and the ^top-state will be the same. This may cut down on transfer of chunks to some extent, but it will not cause any serious harm.

This page written by Robert Rubinoff (rubinoff@cs.cmu.edu)