Re: [rules-dev] else

The other consideration of "<" is that we are thinking of using |" for filters. A() | distinct 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 {failabel1} | A() | {passlabel2} which could also allow A() | distinct | {passlabel2} Mark On 18/08/2011 15:03, Edson Tirelli wrote: > > 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(a)codehaus.org > <mailto: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 <http://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 <http://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(a)lists.jboss.org <mailto: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 <http://www.jboss.com> > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev