[rules-dev] feature request: undo-then

[Mark Proctor]

Greg Barton wrote:
> OK, here's where combining the else and undo would get freaky. :)
>   
Btw did you see my otherwise proposal?

So we would create otherwise-groups, these would ne named groups, like 
activation groups.
Person( location == "london" )
Person ( location == "berlin" )
Person( location == OTHERWISE )

Assuming the three patterns above where each in three different rules. 
What this means is for the given named otherwise-group if a field marked 
as OTHERWISE is not matched by any other rules in that group then it's 
true. Otherwise has long been a feature in decision tables, but it's not 
something I've seen supported in technical rules.

Something else I want to add, particularly focused on systems 
automations is a repeat attribute. We already have a duration attribute, 
that delays the firing of a rule, but what about the rule firing again 
say 30 seconds later if it's still true. So I'd like to add a repeat 
command that takes either a integer duration or a cron like scheduling 
statement, which may also be combined with an initial duration rule.

I've also got ideas around a "execution-group" these would be groups 
who's behaviour would be user defined, probably around some sort of 
event system, which would provide more flexability than the current hard 
coded group behaviours. These execution-groups in theory could contain 
custom conflict resolution strategies and also be able to emulate our 
existing execution control modes too.

So as you can see betwee logical closures, else, otherwise-groups, 
repeats and execution-groups there is still a lot more we can do to 
improve our expressiveness. It is, imho, a necessary step if we are to 
take rule engines further to get mainstream adoption as a generic 
pramming tool - because currently other than very narrow use cases rules 
engines suck for generic programming compared to other languages, where 
with enough flexability they should actually excel. Another key aspect 
for this will be the adoption of properly ontology support, so people 
start creating models that are appropriate for rule engines and not 
bastardising their existing deeply nested pojo models.


Mark


> rule
> when
> 1: Foo()
> 2: Bar()
> 3: Bas()
> then
>   //Everything
> undo-then
>   //When Everything no longer matches
> else 3:
>   //Foo and Bar, No Bas
> undo-else 3:
>   //When (Foo and Bar, No Bas) no longer matches
> else 2:
>   //Foo, No Bar, Bas unknown
> undo-else 2:
>   //When (Foo, No Bar, Bas unknown) no longer matches
> else 1:
>   //No Foo, Bar and Bas unknown
> undo-else 1:
>   //When (No Foo, Bar and Bas unknown) no longer matches
> end
>
> The else clause basically is shorthand that generates another rule, one that's triggerd when the indexed indexed fails.  The undo would fit right in there, and should be triggered immediately when the indexed condition fails to fail. :) i.e. say "else 3" fired first, then condition 3 matches, (and 1,2 still match) then "undo-else 3" and "then" would fire in that order.
>
> Maybe that's just too much. :)
>
> --- On Thu, 2/19/09, Geoffrey De Smet <ge0ffrey.spam at gmail.com> wrote:
>
>   
>> From: Geoffrey De Smet <ge0ffrey.spam at gmail.com>
>> Subject: Re: [rules-dev] feature request: undo-then
>> To: rules-dev at lists.jboss.org
>> Date: Thursday, February 19, 2009, 5:42 AM
>> What would an "else clause" do?
>> Imagine a rule with matches on 5 different fact sets.
>> How many times would the else part match?
>> - none (because it matches at least one)
>> - a very lot (because it matches on any fact set that
>> isn't that one of those 5)
>>
>> The "undo-then" is another concept:
>> it matches when a rule that matched before (in a previous
>> fireAllRules), now no longer matches.
>> "undo-then" probably isn't the best name, so
>> better suggestions are welcome, but "else"
>> isn't a good name for it as it's not about "not
>> matching" but about "no longer matching".
>>
>>
>> Anyway, I 've been thinking and it wouldn't work
>> for all use cases in drools-solver:
>> rule
>>   when
>>     q1 : Queen()
>>     q2 : Queen()
>>     eval(q1.getY() - q2.getY() < 10)
>>   then
>>     a.add(q1.getY() - q2.getY());
>>   undo-then
>>     a.subtract(q1.getY() - q2.getY())
>> end
>> The y of a queen changes, so the subtract wouldn't
>> subtract the exact same number that was added.
>> Any way we could work around that, or is there no avoiding
>> insertLogical?
>>
>> With kind regards,
>> Geoffrey De Smet
>>
>> Mark Proctor schreef:
>>     
>>> Greg Barton wrote:
>>>       
>>>> --- On Wed, 2/18/09, Geoffrey De Smet
>>>>         
>> <ge0ffrey.spam at gmail.com> wrote:
>>     
>>>>   
>>>>         
>>>>> The current workarounds [to undo-then] are
>>>>>           
>> clunky:
>>     
>>>>> - Writing an negative (opposite) rule
>>>>>           
>> isn't efficient:
>>     
>>>>> it means declaring the rule twice effectively.
>>>>>           
>> Also the
>>     
>>>>> negative rule is usually using lots of
>>>>>           
>> or's and
>>     
>>>>> not's which isn't fast.
>>>>>     
>>>>>           
>>>> This would be made easier by...drum roll
>>>>         
>> please...the else clause! :)
>>     
>>>>   
>>>>         
>>> yes we want OPSJ style else statements, edson has an
>>>       
>> idea on how to do that, just a matter of time :(
>>     
>>>> Now, if there was the else clause plus
>>>>         
>> undo-then/closures you could probably write an entire
>> complex ruleset in one rule.  Might as well just use perl,
>> then. :P   
>>     
>>> heh, that's true you would have potentially
>>>       
>> encapsulated 4 possible executions in a single rule.
>>     
>>>>      
>>>>         
>> _______________________________________________
>>     
>>>> rules-dev mailing list
>>>> rules-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>
>>>>   
>>>>         
>>>
>>>       
>> ------------------------------------------------------------------------
>>     
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>       
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>     
>
>
>       
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20090219/834b429e/attachment.html