<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
My current decisions are| vs < I'm tempted ot try | so that it
fits with the filters, to avoid additional symbols.<br>
<br>
I'm relatively happy with {name} and {...code...}, the prior can
just be considered a literal function call, where as the later is an
anonymous literal function.<br>
<br>
I do want to resolve the switch statement. I don't like repeating
'from' for each option:<br>
$o : Object() from stream<br>
( A() > [a] from $o or<br>
B() > [b] from $o or<br>
C() > [c] from $o )<br>
<br>
Possibly a ; separation, similar to the planned accumulate changes.<br>
case( Object() from stream;<br>
A(),<br>
B(),<br>
C() )<br>
<br>
btw the acc planned is<br>
acc( CE*;<br>
<func>*;<br>
<guard>? )<br>
<br>
acc( $o : Order();<br>
$min : min( $o.value ),<br>
$max : max($o.value);<br>
$min > 100 && $max < 100 )<br>
<br>
Mark<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 18/08/2011 15:48, Mark Proctor wrote:
<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: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 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>
<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>