My quick reaction to the suggestions for extensions
that "call one rule from another" is that:
1. in a 'pure' rule base system (whatever that is)
the rules are independent and this type of
tying rules together can lead to maintenance
problems. Consider Ernest's suggestion:
(defrule rule-1
(a b c)
=>
(do-something))
(defrule rule-2 extends rule-1
(d e f)
=>
(do-something-else))
What would this syntax mean? Ernest's idea is that it
could mean that rule-2 is equivalent to
(defrule rule-3
(a b c)
(d e f)
=>
(do-something)
(do-something-else))
However, if we modify rule-1 in any way it may invalidate rule-2
but never be caught. Rule-2 thinks it is behaving as before
but instead fires for different conditions than was
originally intended. I suppose you could also argue
that this type of syntax makes it easier to maintain
rules that share common sets of patterns.
What if the patterns in rule-1 have variables. Can those
variables be used in rule-2? Consider:
(defrule rule-1
(a b ?c)
=>
(do-something ?c))
(defrule rule-2 extends rule-1
(?c d e)
=>
(do-something-else ?c))
Are the 2 ?c variables the same variable?. Is there a chance
a mistake will be made by using a variable in rule-2
that happens to be the same as the one in rule-1?
2. another problem is that one starts trying to think about things
like: should only rule 2 fire if (a b c) and (d e f)
exist. Well in general this is impossible to enforce.
Rules fire (or at least go on the agenda with a chance to
be fired) when their patterns match. The facts don't
always appear at the 'same time' in many systems. So in general
you can't hold rule-1 from firing when (a b c) is asserted. How
do you decide how long to wait? If the facts (a b c) and (d e f)
are asserted at the same time should you get different behaviour
than if they are asserted 2 minutes apart. Why? How to explain this
to users?
3. In another message Alan Littleford suggests that there could be
some implied facts that tie the rules together. Again I
think this 'hidden' behavior will be dangerous. If you
want the rules to be chained together (logically) then
make the connection explicit so that the behaviour is apparant.
My gut feeling is that without some more thought (much
more than I have given) it could lead to problems.
Bob.
-----Original Message-----
From: S. Alexander Jacobson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 22, 2001 6:38 PM
To: Rudolph George-P27574
Cc: Jess Mailing List
Subject: RE: JESS: Some Ideas for Jess 6.1 ...
Maybe, what you may want is to group rules in winner take all sets, a
system where only one rule in a set is allowed to fire when the
patterns of multiple rules in the set are matched.
I'm not sure how you choose the winner. Here are some ideas:
A. if one rule extends another, the extender would win over the
extended, but if two rules both extend the same base rule and both are
matched then they both fire
B. among rules in a set, only the rule with the highest salience fires
C. among rules in a set, the rule with the most constraints fires
I don't know the answer here, but I think I like B better than A or C.
I actually like B a lot if you also add the "extends" syntax Ernest
described (its simpler and faster than adding intermediate rules to AND
with). You would also need a rule-set syntax for B or C to work.
-Alex-
On Sat, 22 Sep 2001, Rudolph George-P27574 wrote:
> One way to interpret this is that
> rule 2 adds additional constraints that rule 1 does not have.
> As you say, you could envision a family of rules like this,
> activated under similar, but not identical circumstances.
>
> But this would also mean that rule 1, would be activated any time
> rule 2 was activated--and under certain circumstances, you may
> want rule 1 NOT to be activated if rule 2 is.
>
> I'm not sure how you'd prevent that without additional extensions
> to the engine, off the top of my head, though.
>
>
> <*> -----Original Message-----
> <*> From: [EMAIL PROTECTED]
> <*> [mailto:[EMAIL PROTECTED]]
> <*> Sent: Saturday, September 22, 2001 2:15 PM
> <*> To: Jess Mailing List
> <*> Subject: JESS: Some Ideas for Jess 6.1 ...
> <*>
> <*>
> <*>
> <*> Someone posted a question recently about "calling one rule from
> <*> another," an interesting idea that doesn't hold up too well to
> <*> scrutiny (how does the rule compiler determine if it's OK
> <*> to pass the
> <*> facts that matched one rule on to another rule as
> <*> arguments?) But it's
> <*> made me think of a related concept: one rule could -extend-
> <*> another. Imagine something like
> <*>
> <*> (defrule rule-1
> <*> (a b c)
> <*> =>
> <*> (do-something))
> <*>
> <*> (defrule rule-2 extends rule-1
> <*> (d e f)
> <*> =>
> <*> (do-something-else))
> <*>
> <*> What would this syntax mean? My idea is that it means that rule-2 is
> <*> equivalent to
> <*>
> <*> (defrule rule-3
> <*> (a b c)
> <*> (d e f)
> <*> =>
> <*> (do-something)
> <*> (do-something-else))
> <*>
> <*> but there are other possible interpretations. Anyone care to comment
> <*> on this? This seems like a really useful way to express the idea of
> <*> having a family of rules that are all activated under
> <*> similar, but not
> <*> necessarily identical, circumstances.
> <*>
> <*> ---------------------------------------------------------
> <*> Ernest Friedman-Hill
> <*> Distributed Systems Research Phone: (925) 294-2154
> <*> Sandia National Labs FAX: (925) 294-2234
> <*> Org. 8920, MS 9012 [EMAIL PROTECTED]
> <*> PO Box 969 http://herzberg.ca.sandia.gov
> <*> Livermore, CA 94550
> <*>
> <*> ------------------------------------------------------------
> <*> ---------
> <*> 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]
> <*> ------------------------------------------------------------
> <*> ---------
> <*>
>
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
