<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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>
</blockquote>
no plans for unlabelled "else". "otherwise" is something different.<br>
<blockquote
cite="mid:CAD7AJnc393zXKqvmKX_YcOXoyStbe=H4nBnz2miib8eG=5C59Q@mail.gmail.com"
type="cite">
<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>
</blockquote>
The labelled consequencei is necessary for compact case statements,
which is very common for signal processing type problems, otherwise
you need to generate a large number of rules with small variations
which is harder to read and maintain. This "case" type of construct
is at the heart of erlang.<br>
o : Object() from stream<br>
(or A( field1 == "1" ) > {a1} from o<br>
A( field1 == "2" ) > {a2} from o<br>
B( field1 == "3 ) > {b1} from o<br>
B( field2 == "5", field 3 == 6 ) > {b2} ) from o<br>
<a class="moz-txt-link-freetext" href="http://www.erlang.org/doc/reference_manual/expressions.html#id75991">http://www.erlang.org/doc/reference_manual/expressions.html#id75991</a><br>
<br>
When can do this one step at a time, no need for a big bang. Each
proposal is an iterative improvement on the last. What i want to
make sure is we have done the design through to completion and
considered all edge cases, so as to avoid a dead end in the syntax
should we add it later. Last thing i want to do is think in one
years time "oh it would be nice to add this but we can't because of
a syntax choice we made earlier and we didn't want to think about
more complex use cases as we assumed they would never be necessary".<br>
<br>
the only issue with {label} as opposed to [label] is what do we
chose for when we want inline code rather than label. I guess we can
say {label} will call a function literal if it exists, otherwise it
attempts to be evaluated as an expression.<br>
<br>
Mark<br>
<br>
<blockquote
cite="mid:CAD7AJnc393zXKqvmKX_YcOXoyStbe=H4nBnz2miib8eG=5C59Q@mail.gmail.com"
type="cite">
<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:0 0 0
.8ex;border-left:1px #ccc solid;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 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>