Task evaluate
This task can be accomplished only by domain dependent rules
which
correspond to the definitions of particular constraints. Every
constraint can be related to two groups of rules:
- rules dedicated to detection whether some parameter violates the
constraint which is being checked and at the same time this
parameter is not registered in the slot
- param-viol of this
constraint. If there is such a parameter, it is put on the
list
in this registration slot. The rules have usually the
following
form:
-
(defrule cons-<constraint name>-y
-
(job evaluate)
(object (is-a constraint)
-
(cons-name <constraint name>)
(active yes))
(object (is-a parameter)
-
(param-name ?a)
... - the detection of the constraint violation
by some parameter
(not (object (is-a constraint)
-
(cons-name <constraint name>)
(viol-param $? ?a $?)))
=>
-
(send [<constraint name>] add-viol-param ?a)
)
- rules detecting whether some parameter is registered in the slot
viol-param of the investigated constraint although it
does not
violate this constraint. If there is such a parameter, it
is
deleted from this registration slot. These rules have the
following general form:
-
(defrule cons-<constraint name>-n
-
(job evaluate)
(object (is-a constraint)
-
(cons-name <constraint name>)
(active yes))
(object (is-a parameter)
-
(param-name ?a)
... - the search for a parameter which does not
violate the constraint
(object (is-a constraint)
-
(cons-name <constraint name>)
(viol-param $? ?a $?))
=>
-
(send [<constraint name>] del-viol-param ?a)
)
If some group consists of more than one rule, the order number
of
the rule forms the last (hyphenated) part of the name of this
rule.
The analysis of some constraint violations is performed only for
those parameters which can violate the investigated constraint.
The
list of these parameters can be found in the slot
cons-param of
the constraint under investigation or it can be indicated
directly
in related rules (what is less elegant but it can save one test
in
the condition part of these rules).
There are two special cases when the last parameter is deleted
from the slot viol-param and the slot is empty (thus
the
constraint
is not violated although in its slot cons-violation
remains the
value yes) or a parameter is asserted into the empty slot
viol-param (thus the constraint is violated although
in its slot
cons-violation remains the value no). In order to keep
all slots
of
every
constraint consistent, there are rules:
-
(defrule violation-no
-
(declare (salience 10))
?a <- (object (is-a constraint)
-
(cons-violation yes)
(viol-param))
=>
-
(send ?a put-cons-violation no)
)
-
(defrule violation-yes
-
(declare (salience 10))
?a <- (object (is-a constraint)
-
(cons-violation no)
(viol-param ? $?))
=>
-
(send ?a put-cons-violation yes)
)
The priority of these rules enables their firing before the
activity
transfer to the next task.