Re: [rules-dev] else

My 2 cents - 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). It would be nice if would do some sort of annotations and then do: @ElseLabel else1 : A() That way we can avoid adding new keywords or special chars (the latter which isn't intuitive in this case). - It took me a couple of q&a with edson to understand how many time it would fire under which conditions. I wonder if we really need this complexity if we can avoid DRY for the users in a more generic way. For example, with ruleParts: rulePart part1 when $p : Person( name == "darth" ) end rulePart part2 when Address( person == $p, city == "deathstar" ) end rule darthOnDeathstar when $part1 $part2 then sout("darth is home") end rule darthNotOnDeathstar when $part1 not ($part2) then sout("darth is away") end This is lower level, but think about: */In the RHS, you can easily extract methods into java classes or DRL functions, but on the LHS, this isn't possible, right?/*

Op 18-08-11 16:48, Mark Proctor schreef: > 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 -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev