[rules-dev] else

[Toni Rikkola]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
> 
> -- 
> With kind regards,
> Geoffrey De Smet
> _______________________________________________
> 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/20110819/911f5c69/attachment.html