CLIPS Temporal relationship between facts/instances and rules

[Julian Lanson]

I am working on a network traffic monitoring tool that internally uses CLIPS to react to the addition of new traffic alerts. For the use case, it is essential that operators are able to add CLIPS rules while the tool is running, which is easy enough to implement. Every time a rule or alert is added, I re-run the environment. However, I'm finding that CLIPS doesn't natively play nice with the concept of time; I have an outstanding need for the following two functionalities:

1) the ability to add a rule such that it DOES NOT trigger on a fact that existed before the rule was added, even if the fact matches the rule's pattern constraints

2) the ability to add a rule that DOES trigger on a fact that existed beforehand, but prioritizes facts that were added first (opposite of the LEX resolution strategy?).

I understand from the documentation that facts and instances have an internal "time tag" that CLIPS uses, but I don't see any way to get at that metadata from within the CLIPS language. If it is not too difficult to edit the CLIPS source to reverse the priority of LEX and/or expose time-tags, I would not be opposed to doing that.

Barring that, I suppose for #1 a solution could be to maintain a "current time" timestamp fact that is updated every time a fact or rule is added. I could add a test CE to added rules that checks that all matched facts' timestamps are >= current time. However, if my understanding of CLIPS internals is correct, every time the timestamp is modified, the RETE algorithm will try to pattern match against old facts again. I imagine this would become computationally expensive over time if there were hundreds of old facts.

[CLIPS Support]

Rules share portions of the pattern matching network when possible, so you can't unlink the shared nodes of a new rule from the matches that have already made for an old rule. However, if you disable the incremental reset behavior you'll prevent the propagation of matches through nodes that can't be shared. This will prevent any activations from being added to the agenda when a new rule is added.

         CLIPS (6.31 6/12/19)

CLIPS> (set-incremental-reset FALSE)

TRUE

CLIPS> (defrule r1 (a) (b) =>)

CLIPS> (defrule r2 (b) (c) =>)

CLIPS> (assert (a) (b) (c))

<Fact-3>

CLIPS> (defrule r3 (a) (b) =>)

CLIPS> (defrule r4 (c) (b) =>)

CLIPS> (agenda)

0      r2: f-2,f-3

0      r1: f-1,f-2

For a total of 2 activations.

CLIPS> (matches r3)

Matches for Pattern 1

f-1

Matches for Pattern 2

f-2

Partial matches for CEs 1 - 2

 None

Activations

 None

(2 0 0)

CLIPS> (matches r4)

Matches for Pattern 1

f-3

Matches for Pattern 2

f-2

Partial matches for CEs 1 - 2

 None

Activations

 None

(2 0 0)

CLIPS>