Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Mark Proctor
On 08/04/2011 13:17, Michael Anstis wrote: OK, answers my question :) The limitation is it will only work for direct accessors. Anything else and it gets too hard and expensive to maintain and track. Mark It is on the "to do" list already. On 8 April 2011 13:11, Mark Proctor

Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Michael Anstis
I agree with both your and Wolfgangs comments; however it does sound remarkably like Mark's "Slot Specific" vision. Perhaps the same issues apply and hence will no doubt be something for Mark and Edson to sleep on :) On 8 April 2011 13:57, Geoffrey De Smet wrote: > > Wouldn't it be great(?) and

Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Geoffrey De Smet
> Wouldn't it be great(?) and an optimisation that with "true modify" > (i.e. no longer a remove and insert) that we could only re-evaluate > rules that contained a pattern on a constraint affected by the update? I doubt if that is possible, consider this case with a calculated getter: class Pe

Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Wolfgang Laun
As all loop-fighting techniques, it won't handle all situations. Apart from loops over 2 or more rules, you still can write $a: Article( $p: price > 1000 ) # slot-specifc on price then modify( $a ){ setPrice( $p - 100 ) } Also, it'll be interesting to see what this will do: $a: Fact()

Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Michael Anstis
OK, answers my question :) It is on the "to do" list already. On 8 April 2011 13:11, Mark Proctor wrote: > On 08/04/2011 12:39, Geoffrey De Smet wrote: > > Related to the modify expression, > > I 've always wondered about this code: > > > > rule "MyRule" > > when > > $p : Person(name

Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Mark Proctor
On 08/04/2011 12:39, Geoffrey De Smet wrote: > Related to the modify expression, > I 've always wondered about this code: > > rule "MyRule" > when > $p : Person(name = "Yoda") > then > modify ($p) { > setAge(300) > } > end > > Doesn't this create an infinite loop?

Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Michael Anstis
Wouldn't it be great(?) and an optimisation that with "true modify" (i.e. no longer a remove and insert) that we could only re-evaluate rules that contained a pattern on a constraint affected by the update? So, rule "MyRule" when $p : Person(name = "Yoda") then modify ($p) { set

Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Esteban Aliverti
Yes, It creates the exact same infinite loop that this code does: rule "MyRule" when $p : Person(name = "Yoda") then $p.setAge(300); update($p); end As far as I know, the results are the same. The modify() is a more compact way to do a lot of set() invocations and an update(). May

Re: [rules-dev] modify (expr) catch 22

2011-04-08 Thread Wolfgang Laun
Reevaluating after change is the whole idea of a production rule system. And you have to guard against it to avoid infinity. age == null age == 0 or use no-loop true -W On 8 April 2011 13:39, Geoffrey De Smet wrote: > Related to the modify expression, > I 've always wondered about this c

[rules-dev] modify (expr) catch 22

2011-04-08 Thread Geoffrey De Smet
Related to the modify expression, I 've always wondered about this code: rule "MyRule" when $p : Person(name = "Yoda") then modify ($p) { setAge(300) } end Doesn't this create an infinite loop? (In my experience it does or at least it takes a lot longer) Because the m