Mark,
The [] syntax for the labels will clash with the
sequencing syntax we've been discussing. Possibly {} or a
unique separator:
{else1} A()
else1 := A()
else1 ?= A()
Considering that Patterns can also take bindings,
probably {} is more distinct:
{else1} a : A()
My vote:
when
{else1} Person( name == "darth" ) // works on patterns
A()
{else2} B()
then
....
otherwise.else1
...
otherwise.else2
...
end
Will we support unlabeled "else" as well?
when
A() and B()
then
...
otherwise
...
end
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?
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.
My .02c.
Edson
2011/8/18 Mark Proctor
<mproctor@codehaus.org>
We have
been looking into designs around else, so here are our
initial
brain storming ideas, which aims at doing more than just
else, but
handling signal processing like situations. "else" is
always triggerd by
the failure of a left propagation. In effect an named
"else" block is
just another terminal node that will result in an
activation on the
agenda. It will have access to declarations prior to the
failure of
propagation in the network.
// Possible syntaxes
[name] ( CE+ ) // no symbol
[name] | ( CE+ )
[name] < ( CE+ )
1)
when
[name1] < Person( name == "darth" ) // works on
patterns
A()
then
....
then.name1
...
end
2)
when
$p : Person( )
[name1] < eval( $p.name ==
"darth" ) // works on evals
A()
then
....
then.name1
...
end
3)
when
[name1] < ( Person( name == "darth" ) and Address(
city == "death
star" ) // works on groups
A()
then
....
then.name1
...
end
This could actuall be extended to have inline "then" too.
In this case
when their is a success propagation on that node it will
result in an
activation placed on the agenda that has access to all the
prior bound
declarations.
1)
when
Person( name == "darth" ) > [name1] // works on
patterns
A()
then
....
then.name1
...
end
2)
when
$p : Person( )
eval( $p.name == "darth" ) > [name1] //
works on evals
A()
then
....
then.name1
...
end
3)
when
( Person( name == "darth" ) and Address( city == "death
star" ) >
[name1] // works on groups
A()
then
....
then.name1
...
end
This can be used with 'or'
when
( A() > [a1] or
B() > [b1] or
C() > [c1] )
D()
then
...
then.a1
....
then.b1
....
then.c1
...
end
It's a little tricker but in theory we can do this
before/afer the 'or' too
This can be used with 'or'
when
[x1] < ( A() > [a1] or
B() > [b1] or
C() > [c1] )
D()
then
...
then.a1
....
then.b1
....
then.c1
...
then.x1
....
end
We could allow [name] as just an inline creation to an
activation that
always passes, which with 'or' could provide a "default".
when
[x1] < ( A() > [a1] or
B() > [b1] or
C() > [c1] or
[default] )
D()
then
Of course both could be supported at the same time
[afailed] < A() > [asuccess]
We could further allow just an inline code block, isntead
of an inline
reference to a block {...code here...} instead of [name1].
We can also use this to do switch like operations, for
erlang style
signal processing, although i'd like to see an improvemet
to the syntax
here, just not sure what it would be...
$o : Object() from stream
( A() > [a] from $o or
B() > [b] from $o or
C() > [c] from $o )
Where as 'or' currently works like java's "|" single
operator, i.e. all
logical branches are tested. We could add a short cut or
operationr
'sor' that would work like "||", so once the first CE
matches in an 'or'
block the rest are igored. We could even consider an 'xor'
....
Finally there is no reason why we couldn't allow other
CE's after the <.
Which would provide for very rich signal processing. For
instance. If
A() fails, it'll propagate to B, if B() fails it'll
activate [a1]
[a1] < B() < A()
This can be nested and using using parenthesis to show
groupings.
( [a1] < B() > [b2] ) < A()
Anyway more food for thought, enjoy :)
Mark
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev