[Indigo]<KRL>document>match-full-imp-loop!1

Much of the complexity in the original KRL-1 engine design came from two desires: wanting to share the maximum information possible between subgoals, and wanting to have control strategies for choosing the right sequence of incorporation and inference steps. In this matcher, there is a user hook (a signal) which enables the user to take over control and do anything fancy. However the basic cycle which is used in the absence of this is a kind of dumb lock-step which should handle a lot of the standard cases at least as efficiently as did the KRL-0 matcher, and will probably cover a few more as well. Each time around the control loop, the following is done:

1. Find every goal in the goal set which: a) is not satisfied; b) there has been a change since the last cycle in its effective description (note that every goal involves some effective description).

2. For each of these, call a function associated with the goal type, to see if anything should be done. One argument to this function is the goal data structure itself, including links to subgoals, etc. Most of the detailed code of the matcher goes into these functions. Side effects of these processes include adding bindings and actions, creating new goals, killing old goals, and modifying effective descriptions.

3. Check to see if the top-level goal is satisfied, or if resources are exhausted. If so, end the control loop and continue to the action and value-return steps described above.

4. Find every descriptor in any effective description which can be used for an extension of that effective description in a way that it has not already been tried, and which is consistent with the signal table for the particular kind of match.