DEFINE-RULESET-TASK
===================

syntax: (define-ruleset-task <ruleset-task-name>
           <task-arguments>
           [:DOCUMENTATION <documentation>]
           [:EXPLANATION <explanation>]
           [:SUBTASKS <list-of-subtasks>]
           :MODE {:SEQUENTIAL |:FORWARD |:BACKWARD}
           [:CONFLICT-RESOLUTION {NIL| :FIRST
           MATCH| :OLDEST-MATCH| :NEWEST-MATCH}]
           ACTIONS
           {<forward-action> | <sequential-action>|
           <backward-action> | <task-action>}*)

Warning: The explanation facility is not sup-
         ported, hence :explanation and :subtasks 
         are ignored.
         :CONFLICT-RESOLUTION is not supported yet!
         Only mode sequential is currently 
         supported!
         The key :no-rules currently works 
         different! 

Every rule, which you define has to belong to a set
of rules. In this set of rules is defined, in which
succession the rules will be applied. Three modes
exist: FORWARD, BACKWARD and SEQUENTIAL. If you choose
FORWARD then a conflict set will be made, in which
is defined, which search strategy (first-match,
newest-match, oldest-match) will be used.

If you choose the sequential mode, then the rules
will be worked out in the right order. The order
of the rules is given by the priority of the rules
or by the order in which they were written down, if no
priorities exist.

There are different evaluation tactics for the
sequential-forward-mode:

do-one ==> {nil | :no-rules}

The system will evaluate the first applieable rule
and returns to the action part of the rule set-task.
If there is no applieable rule available then
':no-rules' will be returned, otherwise nil.

do-all ==> {nil | :no-rules}

All rules in the sort order will be checked and
evaluated. If there is no applieable rule then
':no-rules' will be returned, otherwise nil.

do-while ==> {:condition-failed | :no-rules}

If the form <condition> is fulfilled, then the
rules will be checked in the sort order and the
first applieable rule will be evaluated. This
will be repeated until the <condition> is not
fulfilled anymore or until all rules have been
checked. In the first case ':condition-failed'
will be returned, otherwise ':no-rules'.

do-until <condition>
    ==> {:condition-succeeded | :no-rules}

The rules will be checked in the sorting order and
the first applieable rule will be evaluated. If
the lisp-form <condition> is not fulfilled yet,
then it will be repeated until <condition> is
fulfilled or until all the rules have been checked.
In the first case ':condition-succeeded' will be
returned, otherwise ':no-rules'.


<forward-action>
the rules will be tested in the sorting order and
rules with valid instances will be put in a
conflict set. A single rule will be choosen
with a conflict solution and will be evaluated
for all instances.

The rules will be checked again in sorting order
after the evaluation of a rule. Rules, which have
already been evaluated, will be checked again
if there are new instances. The rules will then be
evaluated only for these again.

A rule without a logical variable will be
evaluated only once at most. Rules which have
already been checked will only be checked again,
if there is a predicate in the premise part,
for which a tell, untell or retell was made.

do-exhaustive ==> {nil | :no-rules}

Warning: yet not implemented!

The explained cycle will be repeated, until
the are no more rules to evaluate. If there
is no rule to execute, then ':no-rules' will
be returned, otherwise nil.

do-while <condition> 
       ==> {condition-failed | :no-rules}

A test will be made before every passage of
the cycle, whether the lisp-form <condition> is
fulfilled or not. The evaluation stops, when the 
<condition> is not fulfilled anymore or when
all rules are checked. In the first case the feedback
will be ':condition-failed', otherwise ':no-rules'.

do-until <condition> 
        ==> {:condition-succeded | :no-rules}

A test will be made after every passage of
the cycle, whether the lisp-form <condition> is
fulfilled or not. The evaluation stops, when the
<condition> is fulfilled or when all rules have been
checked through. In the first case the feedback will
be ':condition-succeded', otherwise ':no-rules'.


Forms of the conflict-solution:

:first-match
The first applieable rule will be evaluated.

:newest-match
The first applieable rule of the last cycle
will be evaluated.

:oldest-match
The first applieable rule of the oldest cycle
will be evaluated.


<backward-action>

In backward-action rule sets there only exists one 
rule-evaluating tactic which tries to verify
the continuation form.

verify <verify_expr> [:once] {<conti-form>}+

Warning: yet not implemented!

A valid instanciation of <verify_expr> will be
searched and then the <continuation-form> 
will be evaluated with this instanciation. If
':once' is missing, then there will be searched
for more instanciations.
VERIFY evaluates the <continuation-form> just like
'ask'. With this all direct readable instancia-
tions and all indirect instanciations will
be generated and the <continuation> forms will
be executed for every instanciation.

example: >(define-ruleset-task HOLIDAYOFFER
             (a-client)
             :documentation 
                "makes a holiday offer"
             :explanation (:description
                (("makes a holiday offer")))
             :mode :SEQUENTIAL
             actions
               (kb-format "~%I give you
               some possible holiday interests")
               (do-one)
               (kb-format 
                 "~%This is all I know"))