|
Hi all,
1.
As some of the
problems related to backward chaining that I described earlier turned
out to be bugs, although there are possible workarounds, I�d like to ask:
could bug fixes/patches be made available even before a next major version
release?
(BTW, when is one due?)
Following is a rather lenghty discussion of a few specific issues related to backward chaining in Jess, so if you are not an 'old Prolog fan' that really can't do without it you'd rather want to skip this...;-) Now here are also
some interesting side effects , that I found and I�d like to share with
you: 2.
Cleaning up the
automatically created need-foo facts: I wished there was some build in support for getting rid of these need-xy facts somehow in an organized manner. What is the problem: a.
The most straight forward
method would be to retract them in the RHS of the rule that 'consumes' them. But if
the rule does not fire this does not help. If you try to make a global rule for clean up there is
another problem: b.
If the need-xy rule
fired, and you have a foo fact as a result, so you can�t just collect the
need-xy facts in a rule/query since there is a hidden condition inserted by Jess
saying (not (foo)) preventing the rule from activation. Ok, so let�s first clean
up the foo facts in a separate rule? Unfortunately that doesn�t work either.
When you retract the foo fact the hidden (not (foo)) activates the need-xy rule
and you are caught in an endless loop! I solved this by inserting ugly �done� flags in the need-xy rules to prevent them from looping. 3.
Some more about (not
(foo)) and backward chaining: I assumed that this wouldn�t work without using salience. When you check if foo is not there, one reason for it not to be there is obviously, that it is NOT YET there. So the rule containin (not (foo) [r1] gets really activated together with the rule need-foo [r2] that is producing foo. To my surprise I found that in all cases that I tried the need-foo rule [r2] fired before the rule containing (not (foo)) [r1] deactivating it even without specifying the salience explicitly. Remember that in the current implementation the �not� CE implies the �explicit� CE. I didn�t succeed to find the proof that it would work always, would it? Is there an implicit conflict resolution/salience mechanism? This would actually be nice. 4. a) I�d like to suggest to make it possible to override the default implicit �explicit� CE when using �not� in backward chaining. b) I think it also makes sense to make it then consistent with the automatic conflict resolution (if any?). That should be enforced only when the �explicit� CE is disabled and you expect it to �backward chain�.
Thanks to all, but especially to Ernest for his really great support for this mail list, Marc |
