The main functionality of the MRS system works as follows.
There is there a function called the (scheduler), which operates to a
large extent in the same manner as the scheduler in timesharing
mainframe systems.
There is there a list of tasks to execute, they are in the variable
agenda, they are a list of S-expressions which can be EVALed.
At every individual step, the scheduler finds the next -- i. e. the
highest priority -- task to execute, from the task list agenda.
Then, the scheduler EVALs (or maybe FUNCALLs) the next task.
New tasks may be added to the agenda, tasks may be removed from the
agenda, the agenda may be rearranged, the EVAL step of course may do
anything at all to the state of the MRS system.
Then, the step repeats.
Following is a simplified scheduler function:
------------------------------------------------------------
(defun scheduler ()
(do ((task (next) (next))) ; Var init repeat
((null task) nil) ; End condition: task is NIL
(eval task))) ; Execute current task
------------------------------------------------------------
And following is a simplified (next) function:
------------------------------------------------------------
(defvar agenda nil) ; List of S-expressions to execute
(defun next ()
(declare (special agenda))
(multiple-value-bind (task agenda) (find-next-task agenda))
task)
------------------------------------------------------------
When the function (find-next-task ...) determines the next task, there
may be there in the knowledge base meta rules as to which task is
given which priority, or something such as that.
For example, one may specify that tasks concerning immediate alarms as
to the machine to be diagnosed, are given higher priority than
ordinary reasoning steps.