8:57 p.m.
How hard would it be to allow something like this in the DRL?
rule "myRule"
when
t: Total()
... // a bunch of complicated fact constraints
then
t.increment();
undo-then
t.decrement();
end
The current workarounds don't 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.
- Using logical inserts is a more heavy weight (= slower).
Here's another description of this feature request from the user mailing
list:
Ah, well that's my point of ignorance, then. I was thinking in
stateless mode. :) And to do what I suggest in a stateful manner would require a
"modifyLogical" type functionality in place of the insertLogical. i.e.
modifyLogical (object) {
//do this when the condition obtains
} else {
//do this when the condition no longer obtains
}
Could be an interesting functionality to have, though.
--
With kind regards,
Geoffrey De Smet
9:44 p.m.
Geoffrey De Smet wrote:
How hard would it be to allow something like this in the DRL?
rule "myRule"
when
t: Total()
... // a bunch of complicated fact constraints
then
t.increment();
undo-then
t.decrement();
end
The current workarounds don't 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.
- Using logical inserts is a more heavy weight (= slower).
This sounds like my logical closure/stateful callback idea that I'd like
to do, where a closure is called when a rule is no longer true. So in
the "then" part you would do something using MVEL like lamba expressions:
logicalClosure( [a, b, c] { my closure code here } );
Where a, b, c are the variables to capture from the surrounding scope
and the my closure here is the code to be executed. In java it would
look something like
final Map vars = new HashMap();
vars.put( "a", a );
vars.put( "b", b);
vars.put( "c", c);
Closure closure = new Closure() {
private Map vars;
public void call() {
a = vars.get(a");
b = vars.get("b");
c = vars.get("c");
.... my closure code here;
}
public void setVars( Map vars ) {
this.vars = vars;
}
}
closure.setVars( vars );
so it forms a sort of encapsulated command that is called when the rule
is no longer true.
Mark
Here's another description of this feature request from the user
mailing list:
> Ah, well that's my point of ignorance, then. I was thinking in
> stateless mode. :) And to do what I suggest in a stateful manner
> would require a "modifyLogical" type functionality in place of the
> insertLogical. i.e.
>
> modifyLogical (object) {
> //do this when the condition obtains
> } else {
> //do this when the condition no longer obtains
> }
>
> Could be an interesting functionality to have, though.
2:25 a.m.
--- On Wed, 2/18/09, Geoffrey De Smet <ge0ffrey.spam(a)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! :)
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
2:58 a.m.
Greg Barton wrote:
--- On Wed, 2/18/09, Geoffrey De Smet <ge0ffrey.spam(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:42 p.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
3:45 p.m.
Geoffrey De Smet wrote:
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".
As I mentioned, i'd do
it as a logical closure using an anonymous code
block, in a similar manner that we do for logical insertions.
Mark
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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5:09 p.m.
Greetings:
It's been interesting watching this thread develop. Originally, I
wasn't going to comment but then I threw caution to the four corners
of the globe and said, "Why not?"
Originally, rulebased systems were simple IF-THEN clauses in a non-
monotonic environment such the engine rules were evaluated as true or
false, those that were true were placed on the agenda to be fired,
which rule to fire next was then selected via some conflict resolution
strategy (such as MEA or LEX), the engine fired that rule, and the
process started all over until there were no more rules to fire.
Along the way, a rule might not be true until some other rule fired
that made it true. Conversely, if some rule fired that made another
rule false that the second rule was removed from the agenda table. A
rule is composed of its data and its logic. Originally, an OR
statement meant that another rule had to be written. Likewise, an
ELSE statement meant that DeMorgan's theorem was applied to the LHS of
the rule and a new rules was written.
Then came OPSJ that featured OR, ELSE and Conditional ELSE where the
ELSE (1) clause would only be evaluated if the first CE was false.
Very selective and very handy. Normally an ELSE fires if ANY of the
CEs are false on the LHS. It seems to me that the idea of "undo" and
"rollback" comes from the database world. If a rule no longer matches
that does not mean that one of the other rules might not change the
data of another CE in another rule so that it does, in fact, match
later. Refraction - a feature of almost all rulebased systems - will
remove a rule (logic+data) once it fires so I would not think that
this is not a matter under consideration.
Now, to the part that mystifies me: If there was a previous
"fireAllRules" and that rule did not match does not mean that the rule
would not match this time we run a "fireAllrules" unless the data and
the rule logic remained unchanged. if a rule never fires and never
will fire, why would it be in the system? Conversely, if the data
changes why would one want to "undo" the run from a previous match in
another run? You wouldn't. Obviously. But that seems to be what has
been promulgated in the foregoing discussion. "No longer matching"
does not mean that the rule will never match in the preset
"fireAllrules" run - you don't know that until all of the rules on the
Agenda (and the changes to the Agenda) have been processed
completely. And by that time it's way too late to consider an "undo"
for those rules.
SDG
jco
"This above all: to thine own self be true,
And it must follow, as the night the day,
Thou canst not then be false to any man."
Hamlet, Act 1, Scene III
http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html
On Feb 19, 2009, at 8:45 AM, Mark Proctor wrote:
Geoffrey De Smet wrote:
> 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".
As I mentioned, i'd do it as a logical closure using an anonymous
code block, in a similar manner that we do for logical insertions.
Mark
>
>
> 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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
7:23 p.m.
I prefer not to think in terms of undo, that lays itself to a particular
use case. Instead I prefer to model it on logical insertions, like
logical insertions when a rule is no longer true we retract the inserted
fact. A closure is an anonymous code block that will be executed using
the given state, think of it as a stateful callback. So in the same way
that a logical inssertion will execute an action that will retract the
fact it inserted a logical closure will execute the anonymous block
using hte previously supplied state - obviosly the onus is on the user
to provide state that would only be valid for execution at that time.
The main reason for this is rules are very good at telling you when
something happens, but not telling you when something stops happeneing
- 'not' CEs are not quite flexible enough for this.
Mark
James C. Owen wrote:
Greetings:
It's been interesting watching this thread develop. Originally, I
wasn't going to comment but then I threw caution to the four corners
of the globe and said, "Why not?"
Originally, rulebased systems were simple IF-THEN clauses in a
non-monotonic environment such the engine rules were evaluated as true
or false, those that were true were placed on the agenda to be fired,
which rule to fire next was then selected via some conflict resolution
strategy (such as MEA or LEX), the engine fired that rule, and the
process started all over until there were no more rules to fire.
Along the way, a rule might not be true until some other rule fired
that made it true. Conversely, if some rule fired that made another
rule false that the second rule was removed from the agenda table. A
rule is composed of its data and its logic. Originally, an OR
statement meant that another rule had to be written. Likewise, an
ELSE statement meant that DeMorgan's theorem was applied to the LHS of
the rule and a new rules was written.
Then came OPSJ that featured OR, ELSE and Conditional ELSE where the
ELSE (1) clause would only be evaluated if the first CE was false.
Very selective and very handy. Normally an ELSE fires if ANY of the
CEs are false on the LHS. It seems to me that the idea of "undo" and
"rollback" comes from the database world. If a rule no longer matches
that does not mean that one of the other rules might not change the
data of another CE in another rule so that it does, in fact, match
later. Refraction - a feature of almost all rulebased systems - will
remove a rule (logic+data) once it fires so I would not think that
this is not a matter under consideration.
Now, to the part that mystifies me: If there was a previous
"fireAllRules" and that rule did not match does not mean that the rule
would not match this time we run a "fireAllrules" unless the data and
the rule logic remained unchanged. if a rule never fires and never
will fire, why would it be in the system? Conversely, if the data
changes why would one want to "undo" the run from a previous match in
another run? You wouldn't. Obviously. But that seems to be what has
been promulgated in the foregoing discussion. "No longer matching"
does not mean that the rule will never match in the preset
"fireAllrules" run - you don't know that until all of the rules on the
Agenda (and the changes to the Agenda) have been processed completely.
And by that time it's way too late to consider an "undo" for those rules.
SDG
jco
/*"This above all: to thine own self be true,*/
/*And it must follow, as the night the day,*/
/*Thou canst not then be false to any man."*/
/*Hamlet, Act 1, Scene III*/
/*http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html*/
On Feb 19, 2009, at 8:45 AM, Mark Proctor wrote:
> Geoffrey De Smet wrote:
>> 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".
> As I mentioned, i'd do it as a logical closure using an anonymous
> code block, in a similar manner that we do for logical insertions.
>
> Mark
>>
>>
>> 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(a)gmail.com
>>>> <mailto:ge0ffrey.spam@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
4:56 p.m.
--- On Thu, 2/19/09, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com> wrote:
What would an "else clause" do?
The else clause(s) could be indexed by condition. This has been implemented by Dr
Forgy's OPSJ. It looked something like this:
rule
when
1: Foo()
2: Bar()
3: Bas()
then
//Everything matches
else 3:
//Foo and Bar match, No Bas
else 2:
//Foo matches, No Bar, Bas unknown
else 1:
//No Foo, Bar and Bas unknown
end
5:11 p.m.
OK, here's where combining the else and undo would get freaky. :)
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(a)gmail.com> wrote:
From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
Subject: Re: [rules-dev] feature request: undo-then
To: rules-dev(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
7:33 p.m.
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(a)gmail.com> wrote:
> From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
> Subject: Re: [rules-dev] feature request: undo-then
> To: rules-dev(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>
>>
> ------------------------------------------------------------------------
>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5799
days inactive
5800
days old
10 comments
4 participants
participants (4)
-
Geoffrey De Smet -
Greg Barton -
James C. Owen -
Mark Proctor