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"))