<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 21/08/2011 13:45, Wolfgang Laun wrote:
<blockquote
cite="mid:CANaj1LcryO=dioxw68JjxgAf+JFBQErq16xoJmkxeKE7Sh5iXA@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On 20 August 2011 21:05, Michael Anstis <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:michael.anstis@gmail.com">michael.anstis@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;">
I like Mario's suggestion.<br>
<br>
Use of a switch statement could also be an option (to muddy
the waters further):-<br>
</blockquote>
<div><br>
Any good reason for calling a "switch" what is usually an
if/elsif? Also, would the branches have an implied "break"? Or
should any number of branches fire for a single match of the
CEs preceding the "switch"? If so, what if "a1" (in the
example) retracts tha fact matching "D()", and then "a2" needs
to be executed?<br>
<br>
Anybody making proposals is cordially invited not just to
provide a syntax silhouette.<br>
<br>
Thank you<br>
-W<br>
</div>
<blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;">
<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 moz-do-not-send="true"
href="mailto:mproctor@codehaus.org" target="_blank">mproctor@codehaus.org</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;">
<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 moz-do-not-send="true"
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 moz-do-not-send="true" 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>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
I proposed something like this, based around the OPSJ labels
approach. It helps if you think of a "then" block as a function
literal and the {func_lit_name} as an inline code fragment that
calls the function literal.<br>
So this:<br>
$o : Object() from stream<br>
( A() | {a} from $o or<br>
B() | {b} from $o or<br>
C() | {c} from $o )<br>
<br>
becomes:<br>
case( Object() from stream; // notice the semi colon to separate the
object that specifies the default 'from'<br>
A() | {a},<br>
B() | {b},<br>
C() | {c} )<br>
then<br>
...<br>
then.a<br>
....<br>
then.b<br>
....<br>
then.c<br>
end.<br>
<br>
The above would currently work like 'or'. All matching branches
would activate. I thought about a short cut or. I think the answer
there is to build a prolog like 'cut' operator, which we need for
queries anyway. However adding 'cut' is far from trivial as it'll
involve substantial changes to the current Rete algorithm, but
assuming we could eventually make those changes, maybe something
like:<br>
case( Object() from stream; // notice the semi colon to separate the
object that specifies the default 'from'<br>
A() | {a} | cut,<br>
B() | {b}| cut,<br>
C() | {c} | cut)<br>
<br>
When thinking about the | symbol, think of unix pipes. The pipe
indicates to filter the output of the pattern, the pipe allows
chaining of these "filters", much like unix, such that the
propagation then goe sfrom the labelled "functional literal" to the
cut CE. I plan to allow the | symbol to be used to integrate user
pluggable filters, such as "distinct". The following will filter all
A() matches using a distinct filter, making sure only distinct
matches are execute by the "a" functional literal. The cut symbpol
ensures that only the first match is found, all other matches (join
attempts) will be stopped - including those in the various 'or'
branches if they exist.<br>
A() | distinct | {a} | cut<br>
<br>
For consistency we will allow time windows to be used as filters.
Over the last 30 seconds find the distinct A and activate on it, but
do not find any more matches after that.<br>
A() | time.window(30s) | distinct | {a} | cut.<br>
<br>
Hopefully that shows why I want to introduce a general purpose "|"
pipe symbol for connecting "filters" and use that in a very generic
way. Rather than introducing various different keywords. <br>
<br>
This syntax is not aimed at business users, who will be using the
guided editor anyway and the verbalisations that come with that,
even more so true once we start to add natural language. So I'm not
overly keen to restrict or limit things for a group of people won't
use the low level syntax anyway.<br>
<br>
<br>
Mark<br>
<blockquote
cite="mid:CANaj1LcryO=dioxw68JjxgAf+JFBQErq16xoJmkxeKE7Sh5iXA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"><font
color="#888888"> <br>
Mark</font>
<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: 0px;">rule "Handle Login"</div>
<div style="margin: 0px;"> when</div>
<div style="margin: 0px;"> $loginRequest
:LoginRequest()</div>
<div style="margin: 0px;"> AuthorizedUsers(
list contains $loginRequest.user ) else
[unsuccessfulLoginAttempt]</div>
<div style="margin: 0px; min-height: 14px;"><br>
</div>
<div style="margin: 0px;"> inner rule
"Check if Admin"</div>
<div style="margin: 0px;"> $p
:AdminRights( user == $loginRequest.user )</div>
<div style="margin: 0px;"> then </div>
<div style="margin: 0px;">
showAdminMenu(); </div>
<div style="margin: 0px;"> end</div>
<div style="margin: 0px; min-height: 14px;"><br>
</div>
<div style="margin: 0px;"> then</div>
<div style="margin: 0px;"> logInUser(
$loginRequest.user );</div>
<div style="margin: 0px; min-height: 14px;"><br>
</div>
<div style="margin: 0px;">
then.unsuccessfulLoginAttempt</div>
<div style="margin: 0px;"> log( "There was
and unsuccessful login attempt with the user
name " + $<a moz-do-not-send="true"
href="http://loginRequest.user.name"
target="_blank">loginRequest.user.name</a>
); </div>
<div style="margin: 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 moz-do-not-send="true"
href="http://then.af/" target="_blank">then.af</a><br>
DO.af<br>
<a moz-do-not-send="true"
href="http://then.at/" target="_blank">then.at</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org"
target="_blank">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>