Hi Mark,<br><br>Since you&#39;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} &lt; 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} &lt; A() &gt; {at}<br>        B()<br>    then<br>        DO<br>    <a href="http://then.af">then.af</a><br>        DO.af<br>    <a href="http://then.at">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&#39;t be used by the Drools engine as it is, but we could implement a kind of &quot;linearization&quot; 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 &quot;or&quot; example:<br><br>rule R1<br>when<br>    (     A() &gt; {a1} or<br>        B() &gt; {b1} or<br>        C() &gt; {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&#39;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 &quot;brainstorming phase&quot; I thought it could worth to consider it at least.<br>
<br>My 2 cents,<br>Mario<br><br>