NL-SOAR / TACAIR INTEGRATION

In a domain such as Tacair NL processing must be interleaved with other task processes. However as a first approximation we have assumed that task processes (such as flying planes, firing and avoiding missiles) are more critical than NL processes. Thus NL processes can only occur when there is no other task process to be carried out. Furthermore NL processing will be interrupted if ever a new task process is required.

As for any integration of NL-Soar, the language-ops-allowed flag is used to determine in what conditions NL processing can begin. The IFOR agents are built using the Michigan goal stack model which means that the language-ops-allowed flag must be on (and only on) the bottom state in the goal stack. Language operators can thus fire in this state and the language-ops-allowed state will become the virtual top state of the NL goal stack.

In the following snapshot of the goal stack, for example, the state labelled S35 will be the only state with the language-ops allowed state. (NB This goal stack is for unchunked NL).

  S: S1
    O: O13 (execute-mission)
       S: S29 (operator no-change)
       O: O18 (racetrack)
          S: S30 (operator no-change)
          O: O22 (fly-to-racetrack)
             S: S32 (operator no-change)
             O: O76 (just-turn)
                S: S35 (operator no-change)
                O: O86 (learn-language)
                   S: S38 (operator no-change)
                   O: O87 (u-constructor2)
                      S: S48 (operator no-change)
                         S: S49 (state no-change)
                         O: O91 generate-operator(empty-op(---->))
                            S: S50 (operator no-change)
                            O: O96 (bead)
 
As in keeping with the rules outlined in language-ops-allowed , this state will also have a attribute ^top-state linking to S1. This will enable the NL process to have a common place in which to store its results.

IMPLEMENTATION

For TACAIR/ NL-SOAR integration, the language-ops-allowed flag is implemented asfollows:-
Mark the state with  language-ops-allowed yes 
If the state :-
       is not marked as a  nl-space  (see below)
   and it has a problem space which is not a 
       top level NL problem-space
   and either
       -  it does not have a substate 
       or it has a substate which has been assigned a problem 
          space which is a top level NL problem-space.

The integration code also includes productions to annotate nl states (i.e those spaces below the language-ops-allowed states) with ^nl-space yes.

 
(sp interface*elaborate*mark-nl*state*first
   (state 
    ^problem-space.name << [list of top-level nl problem spaces] >>
 -->
   ( ^nl-space yes)
 )

(sp interface*elaborate*mark-nl*state*inherit
    (state  ^superstate )
    ( ^nl-space yes)
  -->
    ( ^nl-space yes)
)

IGNORE NEXT BIT - BLIPPING HAS BEEN CORRECTED I THINK!

The above productions work but may cause problems in the future due to the language-ops-allowed flag temoprarily blipping on the lowest NL problem state for one elaboration cycle.

When a state is created, it will not have a substate and the 1st production will fire putting the language-ops-allowed flag on the state. At the same time the 3rd production (interface*elaborate* mark-nl*state*inherit) will fire to put on the nl-space flag. In the next elaboration cycle the 'loa' flag will be retracted due to the presence of the 'nl-space' flag. So a problem will only occur if there are o-supported productions which fire of the presence of the language-ops-allowed flag in the one elaboration cycle that it is present.

Top-state/virtual top state.

The state with the language-ops-flag will also have a link to the real top-state in which nl-results can be stored. The top-state is inherited down through tacair states until the language-ops-allowed state is reached. Below this state, NL may have links to another (virtual) top space which it can use for learning. Thus, in standalone, if the real top-state is found by following the link from the state with language-ops-allowed flag, integration should be smooth.

The current list of nl top-level problem spaces is below. One disadvantage of the current implementation is that this list has to be maintained.

create-operator u-construct top-ps s-construct generator constraints unconstraints completion s-realize s-select d-move-select construct-lexical-expression map-sem-to-lex construct-determiner create-d-plan