Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Oddities of ordering of RHS retractions, unconditional insertions, and rule activations #229
When facts are retracted in the RHS of a rule, they are immediately retracted from the rules network , skipping any batching behavior except for the batching behavior in a single rule activation discussed in #171. However, both logical insertions and unconditional insertions are added to the pending-updates . This can introduce oddities of behavior where, for rules R1 and R2 in the same activation group, RHS retractions from an activation R1 can be visible to an activation of R2 without insertions from the same activation of R1 being visible to the activation of R2.  is a an example of such a test.
Because of batching behavior, it is also possible that for rules R1 and R2 in the same activation group, for both unconditional insertions and RHS retractions, each can activate without any visibility of the consequences of activating the other. I think we've already established that there is no guarantee of rule execution order when salience is not supplied, but a user might expect that if R1 activates first that when R2 activates it will have visibility to the changes from R1's activation, or vice versa if R2 activates first. This is not in fact the case, as can be seen in .
In general, I'd personally consider it best practice to avoid these sorts of scenarios by using truth maintenance except when performance requirements don't allow its overhead. I'd prefer to impose requirements to manage rule order via activation groups when these primitive operations are used rather than making changes that would slow down the preferred truth maintenance path. The issue of neither R1 and R2 seeing the activation of the other before activating seems like a fundamental property of interactions between batching behavior in the pending-updates and the existence of unconditional insertions. We have seen that batching behavior in the pending-updates dramatically improves performance, and I don't think making changes around an edge case of primitive operations would be worth the perf hit to our preferred path (using truth maintenance). I think the problem of making both the retractions and insertions from R1 visible to R2 at the same time could be solved by making  add the retractions done in the RHS to the pending-updates rather than immediately executing them. The insertions and retractions within a single activation are still reordered by the engine but I think the reasoning in  still applies. Also, subjectively, having part but not all of a rule activation be visible seems more surprising to me than either having it be totally visible or totally invisible.
I'd like to think about this a bit more, and am curious what thoughts others have on this. With that said, I tentatively propose the following principles/axioms regarding primitive operations (RHS retractions and unconditional insertions) and rule ordering: