<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 18/08/2011 16:48, Geoffrey De Smet wrote:
<blockquote cite="mid:j2jc7p$kua$1@dough.gmane.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
My 2 cents<br>
<br>
- I don't like using {} for something that doesn't contain code
(the closer we stick to java the easier it is for our users to
learn it).<br>
It would be nice if would do some sort of annotations and then do:<br>
@ElseLabel else1 : A()<br>
That way we can avoid adding new keywords or special chars (the
latter which isn't intuitive in this case).<br>
<br>
- It took me a couple of q&a with edson to understand how many
time it would fire under which conditions.<br>
I wonder if we really need this complexity if we can avoid DRY for
the users in a more generic way.<br>
For example, with ruleParts:<br>
<br>
rulePart part1<br>
when<br>
$p : Person( name == "darth" )<br>
end<br>
<br>
rulePart part2<br>
when<br>
Address( person == $p, city == "deathstar" )<br>
end<br>
<br>
rule darthOnDeathstar<br>
when<br>
$part1<br>
$part2<br>
then<br>
sout("darth is home")<br>
end<br>
<br>
rule darthNotOnDeathstar<br>
when<br>
$part1<br>
not ($part2)<br>
then<br>
sout("darth is away")<br>
end<br>
<br>
This is lower level, but think about:<br>
<b><i>In the RHS, you can easily extract methods into java classes
or DRL functions,<br>
but on the LHS, this isn't possible, right?</i></b><br>
</blockquote>
This one would probably be address by looking properly into a Lisp
like Macro system.<br>
<br>
Mark<br>
<blockquote cite="mid:j2jc7p$kua$1@dough.gmane.org" type="cite"> <br>
Op 18-08-11 16:48, Mark Proctor schreef:
<blockquote cite="mid:4E4D2620.5050309@codehaus.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
The other consideration of "<" is that we are thinking of
using |" for filters. <br>
A() | distinct<br>
It may be we can just achieve this with "|" so we only introduce
a single symbol and the | can work to both the left or right
side of a CE<br>
{failabel1} | A() | {passlabel2}<br>
<br>
which could also allow<br>
A() | distinct | {passlabel2}<br>
<br>
Mark<br>
On 18/08/2011 15:03, Edson Tirelli wrote:
<blockquote
cite="mid:CAD7AJnc393zXKqvmKX_YcOXoyStbe=H4nBnz2miib8eG=5C59Q@mail.gmail.com"
type="cite"><br>
Mark,
<div><br>
</div>
<div> The [] syntax for the labels will clash with the
sequencing syntax we've been discussing. Possibly {} or a
unique separator:</div>
<div><br>
</div>
<div>{else1} A()</div>
<div><br>
</div>
<div> else1 := A()</div>
<div><br>
</div>
<div>else1 ?= A()</div>
<div><br>
</div>
<div> Considering that Patterns can also take bindings,
probably {} is more distinct:</div>
<div><br>
</div>
<div>{else1} a : A()</div>
<div><br>
</div>
<div> My vote:</div>
<div><br>
</div>
<div>when<br>
{else1} Person( name == "darth" ) // works on patterns<br>
A()</div>
<div> {else2} B()<br>
then<br>
....<br>
otherwise.else1<br>
...<br>
otherwise.else2<br>
...</div>
<div>end</div>
<div><br>
</div>
<div> Will we support unlabeled "else" as well?</div>
<div><br>
</div>
<div>when</div>
<div> A() and B()</div>
<div>then</div>
<div> ...</div>
<div>otherwise</div>
<div> ...</div>
<div> end</div>
<div><br>
</div>
<div> If so, what will be the semantics of it? What happens
if an A() is inserted but not B()? vice-versa? What happens
if C() is inserted?</div>
<div><br>
</div>
<div> Regarding inline "consequences", at the moment I am
not really a fan of it. I think it complicates the syntax
unnecessarily at this point but I can be convinced. The
support to else by itself is a big step forward as you know
users frequently ask for that.</div>
<div><br>
</div>
<div> My .02c.</div>
<div><br>
</div>
<div> Edson</div>
<div> </div>
<div><br>
<div class="gmail_quote">2011/8/18 Mark Proctor <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">We have been looking into designs
around else, so here are our initial<br>
brain storming ideas, which aims at doing more than just
else, but<br>
handling signal processing like situations. "else" is
always triggerd by<br>
the failure of a left propagation. In effect an named
"else" block is<br>
just another terminal node that will result in an
activation on the<br>
agenda. It will have access to declarations prior to the
failure of<br>
propagation in the network.<br>
<br>
// Possible syntaxes<br>
[name] ( CE+ ) // no symbol<br>
[name] | ( CE+ )<br>
[name] < ( CE+ )<br>
<br>
1)<br>
when<br>
[name1] < Person( name == "darth" ) // works on
patterns<br>
A()<br>
then<br>
....<br>
then.name1<br>
...<br>
end<br>
<br>
2)<br>
when<br>
$p : Person( )<br>
[name1] < eval( $<a moz-do-not-send="true"
href="http://p.name" target="_blank">p.name</a> ==
"darth" ) // works on evals<br>
A()<br>
then<br>
....<br>
then.name1<br>
...<br>
end<br>
<br>
3)<br>
when<br>
[name1] < ( Person( name == "darth" ) and
Address( city == "death<br>
star" ) // works on groups<br>
A()<br>
then<br>
....<br>
then.name1<br>
...<br>
end<br>
<br>
This could actuall be extended to have inline "then"
too. In this case<br>
when their is a success propagation on that node it will
result in an<br>
activation placed on the agenda that has access to all
the prior bound<br>
declarations.<br>
<br>
1)<br>
when<br>
Person( name == "darth" ) > [name1] // works on
patterns<br>
A()<br>
then<br>
....<br>
then.name1<br>
...<br>
end<br>
<br>
2)<br>
when<br>
$p : Person( )<br>
eval( $<a moz-do-not-send="true"
href="http://p.name" target="_blank">p.name</a> ==
"darth" ) > [name1] // works on evals<br>
A()<br>
then<br>
....<br>
then.name1<br>
...<br>
end<br>
<br>
3)<br>
when<br>
( Person( name == "darth" ) and Address( city ==
"death star" ) ><br>
[name1] // works on groups<br>
A()<br>
then<br>
....<br>
then.name1<br>
...<br>
end<br>
<br>
This can be used with 'or'<br>
when<br>
( A() > [a1] or<br>
B() > [b1] or<br>
C() > [c1] )<br>
D()<br>
then<br>
...<br>
then.a1<br>
....<br>
then.b1<br>
....<br>
then.c1<br>
...<br>
end<br>
<br>
It's a little tricker but in theory we can do this
before/afer the 'or' too<br>
This can be used with 'or'<br>
when<br>
[x1] < ( A() > [a1] or<br>
B() > [b1] or<br>
C() > [c1] )<br>
D()<br>
then<br>
...<br>
then.a1<br>
....<br>
then.b1<br>
....<br>
then.c1<br>
...<br>
then.x1<br>
....<br>
end<br>
<br>
We could allow [name] as just an inline creation to an
activation that<br>
always passes, which with 'or' could provide a
"default".<br>
when<br>
[x1] < ( A() > [a1] or<br>
B() > [b1] or<br>
C() > [c1] or<br>
[default] )<br>
D()<br>
then<br>
<br>
Of course both could be supported at the same time<br>
[afailed] < A() > [asuccess]<br>
<br>
<br>
We could further allow just an inline code block,
isntead of an inline<br>
reference to a block {...code here...} instead of
[name1].<br>
<br>
We can also use this to do switch like operations, for
erlang style<br>
signal processing, although i'd like to see an
improvemet to the syntax<br>
here, just not sure what it would be...<br>
$o : Object() from stream<br>
( A() > [a] from $o or<br>
B() > [b] from $o or<br>
C() > [c] from $o )<br>
<br>
Where as 'or' currently works like java's "|" single
operator, i.e. all<br>
logical branches are tested. We could add a short cut or
operationr<br>
'sor' that would work like "||", so once the first CE
matches in an 'or'<br>
block the rest are igored. We could even consider an
'xor' ....<br>
<br>
Finally there is no reason why we couldn't allow other
CE's after the <.<br>
Which would provide for very rich signal processing. For
instance. If<br>
A() fails, it'll propagate to B, if B() fails it'll
activate [a1]<br>
[a1] < B() < A()<br>
This can be nested and using using parenthesis to show
groupings.<br>
( [a1] < B() > [b2] ) < A()<br>
<br>
Anyway more food for thought, enjoy :)<br>
<br>
Mark<br>
<br>
<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>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
JBoss by Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com">www.jboss.com</a><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
<pre class="moz-signature" cols="72">--
With kind regards,
Geoffrey De Smet</pre>
<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>