It is one of the strengths of rule-based programming that the "procedural forms" are kept at a minimum. Ideally, the LHS is an <i>expression </i>language, with its expressions being evaluated according to the Engine's innate mechanisms. Also, the clear separation of LHS conditions from RHS actions is one of the more attractive features of reactive systems.<br>
<br>I think that the current LHS syntax needs only a minor extension. Without syntactic sugar:<br><br> $bv: Boolean() from ce ( <LHS condition> )<br><br>This always succeeds, firing repeatedly as if it would for the LHS condition being matched and setting $bv to true or firing once for no match with $bv being false. Obviously,<br>
Boolean( $bv: booleanValue == true ) from ce ( <LHS condition> )<br>is the same as just <LHS condition> and<br> Boolean( $bv: booleanValue == false ) from ce ( <LHS condition> )<br>is the same as not(<LHS condition>)<br>
<br>Notice that you could write the not-so-descriptive <br> rule cond when<br>
$bv: Boolean() from ce (...)<br>
then <br> if( $bv ){...} else {...} <br> end<br>
<br>but also the purely rule-based<br><br> rule cond when<br> $bv: Boolean() from ce (...)<br> then end<br><br> rule condTrue when<br> eval( $bv )<br> then<br> // RHS for match of LHS conditions<br> end<br>
rule condTrue when<br>
eval( ! $bv )<br>
then<br>
// RHS for no match of LHS conditions<br>
end<br><br>More sophisticated patterns are possible with two or more booleans:<br> rule condA when $bva: Boolean() from ce (...) then end<br>
rule condB extends condA when $bvb: Boolean() from ce (...) then end<br>Now an extension of condB can refer to both $bva and $bvb.<br><br>-W<br><br><br><div class="gmail_quote">On 18 August 2011 23:35, Mario Fusco <span dir="ltr"><<a href="mailto:mario.fusco@gmail.com" target="_blank">mario.fusco@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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>
DO.at<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> DO.at<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> DO.at<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<div><br>when<br> ( A() > {a1} or<br> B() > {b1} or<br> C() > {c1} )<br> D()<br>then<br></div> 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><font color="#888888">Mario<br><br>
</font><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>