Re: [rules-dev] Slot Specific and Refraction

I suppose that the proposed refraction (with onChange as control mechanism) is based on "fine-grained" WM updates - the question is, how fine the grain is. This is important for determining whether a rule will fire again, due to the LHS becoming false and then true again. (These are contrived, but simple, examples.) rule "insert-retract" when $a : Elem() $b : Elem( this != $a ) then retract( $a ); // now LHS is false insert( $a ); // now LHS true again end rule "increment-both-facts" when $a : Elem( $slot : slot ) $b : Elem( slot == $slot, this != $a ) then modify( $a ){ setSlot( $a.getSlot() + 1 ) } // now LHS is false modify( $b ){ setSlot( $b.getSlot() + 1 ) } // now LHS is true again end rule "increment-both-slots" when $a : Elem( $slot1 : slot1, slot2 == slot1 ) then modify( $a ){ setSlot1( $a.getSlot1() + 1 ), // now LHS is false setSlot2( $a.getSlot2() + 1 ) // now LHS is false } end I'm guessing that "insert-retract" and "increment-both-facts" will loop even with the proposed change. I'm not quite so sure about the fate of "increment-both-slots", but I'd bet my money on "loop" here, too. But won't a "naive" interpretation of the refraction as proposed lead to the assumption that none of these three rules will loop? Anyway, a precise definition of when and how the true-false and false-true transitions may occur will be essential. =*= Another question arises in combination with "virtual" fields. class Board { // a square board int dim; int getDim(){ return dim; } void setDim( int dim ){ this.tim = dim; } int getFields(){ return dim*dim; } } rule "enlarge-board" when Limit( value ) $b : Board( onChange == [fields], fields < value ) then modify( $b ){ setDim( $b.getDim() + 1 ) } end I suppose this will not loop (until Limit.value is reached), but I (being naive!) did say onChange == [fields]. -W On 31 July 2010 20:53, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: