Use of a switch statement could also be an option (to muddy the waters further):-
Any good reason for calling a "switch" what is usually an if/elsif? Also, would the branches have an implied "break"? Or should any number of branches fire for a single match of the CEs preceding the "switch"? If so, what if "a1" (in the example) retracts tha fact matching "D()", and then "a2" needs to be executed?
Anybody making proposals is cordially invited not just to provide a syntax silhouette.
Thank you -W
rule R1 when D()
switch A() then a1 B()
then
b1
C()
then
c1
switch then d1 end
ruleruleName {
when
{conditioni evaluate (expression)}
then
{[action1 ... actionm]}
else
{[action1 ... actionp]}
};
OPSJ is the only engine that i know of that uses labels:
x.name == obj,
x.weight == "light",
x.location != g.location);
mky: monkey;
[4] (mky.holds == obj);
} do {
makegoal("walkto", loc);
} else( 4 ) {
makegoal("holds", obj);
}
Although I would encourage people to think beyond simple "if/else",
the proposal I put forward would allow for tree like data flows for
signal processing - which will map very nicely to GUI tooling.
Mark
On 19/08/2011 13:56, Toni Rikkola wrote:
I got the same feeling that Geoffrey had about readability.
We added "from" its really easy to get, why not add "else".
when
Person( name == "darth" ) else [darthIsMissing]
A()
then
....
then.darthIsMissing
log("Darth was never found");
end
or
when
Person( name == "darth" ) else { log("Darth was never
found"); }
A()
then
....
end
"Inline then" could be done with inner rules. Similar to what
Mario suggested.
rule "Handle Login"
when
$loginRequest :LoginRequest()
AuthorizedUsers( list contains
$loginRequest.user ) else [unsuccessfulLoginAttempt]
inner rule "Check if Admin"
$p :AdminRights( user ==
$loginRequest.user )
then
showAdminMenu();
end
then
logInUser( $loginRequest.user );
then.unsuccessfulLoginAttempt
log( "There was and unsuccessful login
attempt with the user name " + $loginRequest.user.name );
end
Toni
On Aug 19, 2011, at 2:59 PM, Geoffrey De Smet wrote:
I like Mario's proposal
because I can actually read it.
Those special chars | < are gibberish to me.
The only reason we're not debating to use a new readable,
intuitive keyword, is because of the back-wards
compatibility issues involved.
But using unreadable, unintuitive special char just for
that, is probably not a good idea.
I wonder if we reserve new keywords by prefix them with
reserved special char like "@"?
Then we can introduce as many keywords as we want without
breaking backwards compatibility.
Who's our target users for DRL authors?
A) Supersmart computer science guys
B) Blue collar Java programmers
C) Domain experts (= not programmers)
I 'd classify "{notA} < A()" as (given some time to learn
it) readable for A, but not for B and C.
Op 18-08-11 23:35, Mario Fusco schreef:
Hi Mark,
Since you're gathering 2 cents here and there I decided to
add also mine even if I am pretty sure that I am still
missing the whole picture and anyway at the moment I
cannot see all the consequences of what I am going to
propose.
To tell you the truth I find the label syntax not very
intuitive and I was wondering if we could avoid it in some
way. In the end what the 90% of the users are asking for
is just something like:
rule R
when
A()
then
do something
else
do something else
end
while we are going to give them something that is not
exactly the same:
rule R
when
{notA} < A()
then
do something
then.notA
do something else
end
In particular I was thinking if we could keep the when ...
then ... else syntax that should be familiar to the
biggest part of the users and at the same time obtain a
flexibility similar to the one provided by the labels
syntax. Probably we could do it with a kind of nested
rules so, for instance, the rule:
rule R1
when
B()
then
DO
rule R1A
when
A()
then DO.at
else
DO.af
end
end
Of course the nested rule couldn't be used by the Drools
engine as it is, but we could implement a kind of
"linearization" process at compile time that translates it
more or less as:
rule R1
when
( A() > {a1} or
B() > {b1} or
C() > {c1} )
D()
then
DO
then.a1
DO.a1
then.b1
DO.b1
then.c1
DO.c1
end
could be written as:
rule R1
when
D()
then
DO
rule R1A
when
A()
then
DO.a1
end
rule R1B
when
B()
then
DO.b1
end
rule R1C
when
C()
then
DO.c1
end
end
and then linearized at compile time in a similar way as I
wrote before.
Once again I still haven't evaluated all the implications
of my suggestion neither I know if we can cover with it
all the cases proposed by Mark. I am pretty sure I am
missing something important to be honest, but since we are
in a "brainstorming phase" I thought it could worth to
consider it at least.