[EMAIL PROTECTED] wrote:
>
> I think [EMAIL PROTECTED] wrote:
> >
> >
> > Ernest:
> >
> > Thanks for your reply. Your work around for the double rule firing worked, i.e.,
> > (not (seen ?s ?i ?o) & (assert (seen ?s ?i ?o)).
> > I did some reading abou the rete algorithm and still don't understand why
> > asserting or modifying the source attribute makes the rule fire. The rule is
> > only doing a test on the id attribute.
> >
> > I have prototyped other rule engines (OPSJ and Gensym's G2) and have found
> > differences in rule execution. The other rule engines only fire rules when the
> > attributes in question are asserted or modified. For example if I have an object
> > OBJ1 with attributes ATTR1 and ATTR2. If I have a rule that satisfies a
> > condition on ATTR1, changing ATTR2 does not make the rule fire.
>
> Well, you've named two systems that apparently behave the way you
> expect, but there are at least two (Jess and CLIPS) that behave the
> way Jess does. Witness:
>
> CLIPS> (watch rules)
> CLIPS> (deftemplate t (slot s1) (slot s2))
> CLIPS> (deffacts facts (t (s1 1) (s2 2)))
> CLIPS> (defrule r (t (s1 ?x)) => )
> CLIPS> (reset)
> CLIPS> (run)
> FIRE 1 r: f-1
> CLIPS> (modify 1 (s2 3))
> <Fact-2>
> CLIPS> (run)
> FIRE 1 r: f-2
> CLIPS>
Small clarification: CLIPS "goes" both ways. The distinction is
facts/templates vs. objects.
If one uses COOL objects in CLIPS, one *can* get the kind of behavior
cited for OPSJ and Gensym's G2 objects, to wit:
CLIPS (V6.10 07/01/98)
CLIPS>
(watch rules)
CLIPS> (defclass C (is-a USER)
(role concrete)
(pattern-match reactive)
(slot x (create-accessor read-write))
(slot y (create-accessor read-write)))
CLIPS> (definstances i (c1 of C (x 1) (y 1)))
CLIPS> (defrule r (object (is-a C) (x ?)) => )
CLIPS> (reset)
CLIPS> (run)
FIRE 1 r: [c1]
CLIPS> (modify-instance [c1] (y 2))
TRUE
CLIPS> (run)
CLIPS> (modify-instance [c1] (x 2))
TRUE
CLIPS> (run)
FIRE 1 r: [c1]
CLIPS>
This is not necessarily better or worse. I don't believe it is
inherently something required of a good object-oriented rule system,
although one often sees this behavior. It often seems more natural.
An object-oriented exception to slot-specific rule activations is
NeOpus, a Smalltalk expert system shell. It had some intriguing OO
innovations, but only triggers inferences on whole objects. This really
makes sense from an encapsulation viewpoint, as changing state in an
object invalidates the state and result of non-trivial accessors.
Rule-based programming with objects often leads to developers exposing a
lot of object internals through slot references. Using methods can lead
to predicate "reuse" at a coding level that avoids *recoding* common
patterns repeatedly (OTOH, this can lead to unnecessary re-inferencing).
For anyone interested in the OO language/RETE nexus or simply a
Smalltalk RETE implementation, check out:
http://www-poleia.lip6.fr/~fdp/NeOpus.html
http://www-poleia.lip6.fr/~fdp/NeOpus.html#Publications
- Mike Smith
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
