[rules-dev] else
Michael Anstis
michael.anstis at gmail.com
Sat Aug 20 15:05:27 EDT 2011
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 at codehaus.org> 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=/com.ibm.websphere.ilog.jrules.doc/Content/Business_Rules/Documentation/_pubskel/JRules/ps_JRules_Global1895.html
>
> 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 at lists.jboss.orghttps://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
>
>
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> _______________________________________________
> 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/20110820/6d3e80a6/attachment.html
More information about the rules-dev
mailing list