Illogical unmatch in clips

Question

i have a problem with a rule match in Clips, in particular i can't understand why this rule doesn't actives!. I have a module called REASONING where i defined a fact with this deftemplate (deftemplate planning (slot value (allowed-values start stop))). First time i focus on this module i assert this fact with this rule

(defrule start-reasoning
 (declare (salience 90))
 (not (planning))
 =>
 (assert (planning (value start)))
)

Nextly, this fact will be never retract but only modified its slot. In the same module where i defined planning i have an other rule, where it's changed value from start to stop.

(defrule plan-done
    (declare (salience 60))
    ?<-(planning(value start)
    =>
    (modify ?p (value stop))
)

This is the last rule activated by this module. After that Clips execute a pop-focus. Now when it's the turn to get focus again on this module, i find (planning (value stop))

f-4839  (explore-memory (pos-r 2) (pos-c 5) (direction west)(action turnleft)
(param1 nil) (param2 nil) (param3 nil) (open-depth 0) (ident 0))
f-4843  (planning (value stop))
f-4845  (exec (step 0)(action turnleft)(param1 nil)(param2 nil) (param3 nil))
f-5029  (exec (step 1)(action turnright)(param1 nil)(param2 nil)(param3 nil))

So i expect that rule written under must be actived but it doesn't happen! The condition to change again slot value it's inside module PLAN_MANAGER, whereby i can active no other rules inside REASONING until Clips doesn't exec focus on PLAN_MANAGER.

(defrule go-to-plan-manager
  (declare (salience 90))
  (planning (value stop))
  =>
  (focus PLAN_MANAGER)
)

The strange thing it's that if i call matches function i obtain this output.

>(matches go-to-plan-manager)
Matches for Pattern 1
f-4843
Activations
None

Anybody can help me to understand why CLIPS doesn't puts in agenda go-to-plan-manager ? Where i'm wrong?

score 0 · Accepted Answer · answered Dec 12 '15 at 20:16

Given the lack of a reproducible example to demonstrate otherwise, the most likely explanation is that the go-to-plan-manager executed at some point before the focus was originally popped. Refocusing on a module only changes the agenda from which activations are pulled, but it doesn't reactivate rules that have previously been executed.

The simplest example I can create based on the code fragments you included suggests that your go-to-plan-manager rule is going to execute immediately after the plan-done rule unless there's some other rule with a salience of 90 or higher that pops the focus before the go-to-plan-manager rule can execute.

CLIPS> (deftemplate planning (slot value (allowed-values start stop)))
CLIPS> 
(defrule start-reasoning
 (declare (salience 90))
 (not (planning))
 =>
 (assert (planning (value start))))
CLIPS> 
(defrule plan-done
    (declare (salience 60))
    ?p<-(planning(value start))
    =>
    (modify ?p (value stop)))
CLIPS> 
(defrule go-to-plan-manager
  (declare (salience 90))
  (planning (value stop))
  =>
  (printout t "go-to-plan-manager executed" crlf))
CLIPS> (reset)
CLIPS> (watch rules)
CLIPS> (run)
FIRE    1 start-reasoning: *
FIRE    2 plan-done: f-1
FIRE    3 go-to-plan-manager: f-2
go-to-plan-manager executed
CLIPS> (matches go-to-plan-manager)
Matches for Pattern 1
f-2
Activations
 None
(1 0 0)
CLIPS>

Thanks a lot, there was a rule with higher salience that executed pop-focus before that go-to-plan-manager could be executed. — xeon88, Dec 13 '15 at 14:57

Illogical unmatch in clips

1 Answers1