Hello-
I had some code that was working great just before it stopped working in a
very unusual place. It took me forever to realize that I unintentionally
had two rules of the same name. Fixing this fixed the 'unrelated'
problem. I found this odd but I was unable to determine what the
significance was at that time due to the complexity of the application and
time constraints. Then it happened again.
Normally, issuing a defrule with a duplicate name should simply replace
the definition and the network adjusted appropriately. This does indeed
seem to happen for most cases. I now have some simplified code that
demonstrates when it doesn't, but I'm still not sure exactly what is going
on. Basically, part of the network seems to become disjoined when the
replacement rule is added, which explains how my partially running
application began stopping at an unusual point.
View the differences in the following when the indicated defrule name is
changed:
;;; BEGIN CODE
(watch all)
(defrule phase-change
(declare (salience -10))
?phase-fact <- (phase ?x)
?phase-list-fact <- (phase-list ?next $?remaining)
=>
(retract ?phase-fact ?phase-list-fact)
(assert (phase ?next))
(assert (phase-list $?remaining)))
(defrule a
(phase a)
=>
(printout t "phase a" crlf))
(defrule b
(phase b)
=>
(printout t "phase b" crlf))
(defrule aa ;;;;;; change 'aa' to 'a' to break it
(phase aa)
=>
(printout t "phase aa" crlf))
(assert (phase a))
(assert (phase-list b c d e))
(run)
;;; END CODE
It seems I had to use salience to get it to break. Hope this is a simple
bug for somebody else to fix . . . .
-Dave Barnett
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
