[rules-dev] A remarkable flop

[Wolfgang Laun]

Given classes Switch and Track, and the "natural" class hierarchy
representing state changes for these two elements:
   ElementState
   TrackState extends ElementState ("free/occupied")
   SwitchState extends TrackState (adds "left/right/moving")
Now we have rules for updating Switch and Track elements, like this one:
   rule "Xyz state update"
   when
       $s: XyzState( $id: id, ... )
       $e: Xyz( id == $id )
   then
     //...update $e, retract $s
   end
and, since we want to catch bad ids, also
   rule "Xyz state for unknown element"
   when
      $s: XyzState( $id: id )
      not Xyz( id == $id )
  then
      //... diagnostic, retract $s
  end

Best practice, wouldn't you say?

Testing by inserting a few of SwitchState objects works fine:
   updated: Switch 5 RIGHT occupied
   updated: Switch 2 RIGHT
   updated: Switch 1 RIGHT occupied
 so everything is allright, wouldn't you say?

Add another SwitchState for Switch "4" to the test, and suddenly:
  updated: Switch 4 RIGHT
  track state for unknown element 5
  updated: Switch 2 RIGHT
  updated: Switch 1 RIGHT occupied
What's this?!

After some headscratching I realized that the negative rule for the
SwitchState's superclass TrackState produces another activation, since, for
any Switch element with an id x there clearly isn't a Track element with id
x! This activation *occasionally *precedes the activation for the match in
the "update" rule.

This is annoying. Of course, negative salience for the "not" rules fixes
this, but who would have thought that you need it with conditions
(seemingly!) describing disjoint situations. And the negative salience is
counter-intuitive, since normally you'd perform the check "no such element"
*before *permitting any update action.

Remarkable.
Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101211/3d5034da/attachment.html