Re: [rules-dev] else

I like Mario's suggestion. Use of a switch statement could also be an option (to muddy the waters further):-

rule R1 when D() switch A() then a1 B() then b1 C() then c1 switch then d1 end I definitely don't like the ">" "{..}" notation. Cheers, Mike On 20 August 2011 00:34, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > For further info, this is what ilog do. They only allow an implicit > "else" on the last "evaluate" expression. Which while simple is quite > restrictive.: > > http://publib.boulder.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=/c... > > 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); > } > > 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 > {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 listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > -- > With kind regards, > Geoffrey De Smet > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > _______________________________________________ > rules-dev mailing listrules-dev@lists.jboss.orghttps://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