A remark on the proposed syntax: onChange == [name1, name2, name3] defines a set of slots by explicit enumeration, whereas onchange == [ ! name1, !name2, *] defines a set my subtracting the enumerated slots from the full set. I think that using onChange == [ ! name1, *, name2 ] doesn't make sense, since "name2" is already in '*'. This means that only negated slot names make sense in combination with '*'. This, in turn, means that '*' in addition to a list of negated slots is redundant. Therefore, only a list of all positive *or *all negated slot names makes sense. Thus, all possible sets can be defined by permitting nothing but one of these forms: onChange == [<name>,...] onChange == [*] onChange != [<name>,...] // subtract all enumerated from full set One can also permit these two identical forms: onChange == [] onChange != [*] and onChange != [] which is the same as onChange == [*] Best -W On 31 July 2010 20:53, Mark Proctor <mproctor(a)codehaus.org&gt; wrote:

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: