Because the Create-operator space (which responds to the impasse on
learn-language) copies and walls off the language state during
learning, the conditions for reconsidering the LL operator lead to the
"blippability" of the comprehension process. One opportunity that is always
available is the possibility of reconsidering the LL operator when a
x-constructor operator is made acceptable by the Create-operator space
("blipping from below" or, less idiomatically, resolving the impasse).
"Blipping from above" is accomplished by the addition of search control that
causes a reconsider whenever there is a proposal for another LL operator for
a word later in the sentence than the one that led to the proposal of the
current one. Such search control knowledge will generate a reconsider
preference for the selected, blippable LL operator. This has the effect
that if a new word arrives before the impasse terminated naturally (by
producing a constructor operator), the impasse will be terminated
prematurely. It is possible that the LL operator that was previously in the
slot will be reselected, but the "blipping" will have caused the stack to
collapse in any case.
A consequence of designing comprehension to be blippable is that it creates
a learning/training trade-off. When words are coming into the phonological
buffer in real-time there is rarely enough time to learn from scratch and
the system will generally be blipped from above before a constructor can be
completed. Since chunking occurs throughout the goal stack, however, a
second (or third...) run over the same data will take advantage of the
chunks created in lower spaces to build a top-level constructor.
Alternatively, data can be run in a stand-alone version of NL-Soar where
time can be stretched to allow for the learn-language to
self-terminate. This is the usual way of running NL-Soar.