rule ruleName {
   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);
}

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
        {af} < A() > {at}
        B()
    then
        DO
    then.af
        DO.af
    then.at
        DO.at
end

could be rewritten as it follows:

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_1
    when
        A()
        B()
    then
        DO
        DO.at
end

rule R1_2
    when
        not A()
        B()
    then
        DO
        DO.af
end

In the same way the "or" example:

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.

My 2 cents,
Mario

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev