Fork me on GitHub
#clara
<
2016-09-27
>
wparker10:09:14

@devn the reason for truth maintenance governed facts to have more information available is that when facts are inserted using truth maintenance, the memory stores information to the effective of “this fact was inserted from this rule based on X other facts”. The code in the memory is at https://github.com/rbrush/clara-rules/blob/0.12.0/src/main/clojure/clara/rules/memory.cljc#L685 This is only called if truth maintenance is used; if you use unconditional insertions it won’t be. You can see the conditional on that at https://github.com/rbrush/clara-rules/blob/0.12.0/src/main/clojure/clara/rules/engine.cljc#L228 It is a little confusing because the ProductionNode will add “activations” in any case, but Clara batches insertions from them in the activation-memory as a sort of queue, then pops them off when you call fire-rules https://github.com/rbrush/clara-rules/blob/0.12.0/src/main/clojure/clara/rules/engine.cljc#L1483 As far as the reasoning behind this, truth maintenance does have some performance cost. If you do want to keep track of unconditional assertions, I suspect a way to do it with listeners could be found.

wparker10:09:10

As far as simplicity, I’d suggest keeping in mind that rules can fire based on intermediate state in the rules engine that won’t be reflected in the final state after the fire-rules loop finishes, and unconditional insertions can thus reflect such intermediate state. In our case, we have a mostly stark dividing line between “types of facts that can be inserted from outside the session” and “facts that can be created by rules”; our unconditional insertions tend to be from rules whose LHS looks for things of the former types. Thinking through how the intermediate state of the rules engine will play out can get pretty tricky and may be non-guaranteed behavior depending on the use case. There are certainly many legitimate use cases for unconditional insertions though.