I like Mario's suggestion.<br><br>Use of a switch statement could also be an option (to muddy the waters further):-<br><br>rule R1<br> when<br> D()<br>
switch<br> A()<br> then<br> a1<br> B()<br>
then<br>
b1<br>
C()<br>
then<br>
c1<br>
switch<br> then<br> d1<br>end<br><br>I definitely don't like the ">" "{..}" notation.<br><br>Cheers,<br><br>Mike<br><br><div class="gmail_quote">On 20 August 2011 00:34, Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org" target="_blank">mproctor@codehaus.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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.:<br>
<a href="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" target="_blank">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</a><br>
<pre><span>rule</span> <span>ruleName</span> {
<span> when</span>
{<span>conditioni</span> evaluate (<span>expression</span>)}
<span> then</span>
{[<span>action1 </span>... <span>actionm</span>]}
<span>else</span>
{[<span>action1</span> ... <span>actionp</span>]}
};
OPSJ is the only engine that i know of that uses labels:
<a href="http://x.name" target="_blank">x.name</a> == obj,
x.weight == "light",
x.location != g.location);
mky: monkey;
[4] (mky.holds == obj);
} do {
makegoal("walkto", loc);
} else( 4 ) {
makegoal("holds", obj);
}
</pre>
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.<br><font color="#888888">
<br>
Mark</font><div><div></div><div><br>
<br>
<br>
On 19/08/2011 13:56, Toni Rikkola wrote:
<blockquote type="cite">
<div>I got the same feeling that Geoffrey had about readability.</div>
<div><br>
</div>
<div>We added "from" its really easy to get, why not add "else".</div>
<div><br>
</div>
<div>when<br>
Person( name == "darth" ) else [darthIsMissing] <br>
A()<br>
then<br>
....<br>
then.darthIsMissing<br>
log("Darth was never found");</div>
<div>end</div>
<div><br>
</div>
<div>or</div>
<div><br>
</div>
<div>when<br>
Person( name == "darth" ) else { log("Darth was never
found"); }<br>
A()<br>
then<br>
....<br>
end</div>
<div><br>
</div>
<div>"Inline then" could be done with inner rules. Similar to what
Mario suggested.</div>
<div><br>
</div>
<div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">rule "Handle Login"</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> when</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> $loginRequest :LoginRequest()</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> AuthorizedUsers( list contains
$loginRequest.user ) else [unsuccessfulLoginAttempt]</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;min-height:14px"><br>
</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> inner rule "Check if Admin"</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> $p :AdminRights( user ==
$loginRequest.user )</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> then </div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> showAdminMenu(); </div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> end</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;min-height:14px"><br>
</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> then</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> logInUser( $loginRequest.user );</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;min-height:14px"><br>
</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> then.unsuccessfulLoginAttempt</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"> log( "There was and unsuccessful login
attempt with the user name " + $<a href="http://loginRequest.user.name" target="_blank">loginRequest.user.name</a> ); </div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">end</div>
</div>
<div><br>
</div>
<div>Toni</div>
<br>
<div>
<div>On Aug 19, 2011, at 2:59 PM, Geoffrey De Smet wrote:</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#ffffff"> I like Mario's proposal
because I can actually read it.<br>
Those special chars | < are gibberish to me.<br>
<br>
The only reason we're not debating to use a new readable,
intuitive keyword, is because of the back-wards
compatibility issues involved.<br>
But using unreadable, unintuitive special char just for
that, is probably not a good idea.<br>
I wonder if we reserve new keywords by prefix them with
reserved special char like "@"?<br>
Then we can introduce as many keywords as we want without
breaking backwards compatibility.<br>
<br>
Who's our target users for DRL authors?<br>
A) Supersmart computer science guys<br>
B) Blue collar Java programmers<br>
C) Domain experts (= not programmers)<br>
<br>
I 'd classify "{notA} < A()" as (given some time to learn
it) readable for A, but not for B and C.<br>
<br>
Op 18-08-11 23:35, Mario Fusco schreef:
<blockquote type="cite">Hi Mark,<br>
<br>
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.<br>
<br>
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:<br>
<br>
rule R<br>
when<br>
A()<br>
then<br>
do something<br>
else<br>
do something else<br>
end <br>
<br>
while we are going to give them something that is not
exactly the same:<br>
<br>
rule R<br>
when<br>
{notA} < A()<br>
then<br>
do something<br>
then.notA<br>
do something else<br>
end <br>
<br>
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:<br>
<br>
rule R1<br>
when<br>
{af} < A() > {at}<br>
B()<br>
then<br>
DO<br>
<a href="http://then.af/" target="_blank">then.af</a><br>
DO.af<br>
<a href="http://then.at/" target="_blank">then.at</a><br>
<a href="http://DO.at" target="_blank">DO.at</a><br>
end<br>
<br>
could be rewritten as it follows:<br>
<br>
rule R1<br>
when<br>
B()<br>
then<br>
DO<br>
rule R1A<br>
when<br>
A()<br>
then<br>
<a href="http://DO.at" target="_blank">DO.at</a><br>
else<br>
DO.af<br>
end <br>
end <br>
<br>
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:<br>
<br>
rule R1_1<br>
when<br>
A()<br>
B()<br>
then<br>
DO<br>
<a href="http://DO.at" target="_blank">DO.at</a><br>
end<br>
<br>
rule R1_2<br>
when<br>
not A()<br>
B()<br>
then<br>
DO<br>
DO.af<br>
end<br>
<br>
In the same way the "or" example:<br>
<br>
rule R1<br>
when<br>
( A() > {a1} or<br>
B() > {b1} or<br>
C() > {c1} )<br>
D()<br>
then<br>
DO<br>
then.a1<br>
DO.a1<br>
then.b1<br>
DO.b1<br>
then.c1<br>
DO.c1<br>
end<br>
<br>
could be written as:<br>
<br>
rule R1<br>
when<br>
D()<br>
then<br>
DO<br>
rule R1A<br>
when<br>
A()<br>
then<br>
DO.a1<br>
end <br>
rule R1B<br>
when<br>
B()<br>
then<br>
DO.b1<br>
end <br>
rule R1C<br>
when<br>
C()<br>
then<br>
DO.c1<br>
end<br>
end <br>
<br>
and then linearized at compile time in a similar way as I
wrote before.<br>
<br>
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.<br>
<br>
My 2 cents,<br>
Mario<br>
<br>
<pre><fieldset></fieldset>
_______________________________________________
rules-dev mailing list
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
With kind regards,
Geoffrey De Smet</pre>
</div>
_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
rules-dev mailing list
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
<br>
</div></div></div>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br></blockquote></div><br>