[rules-dev] else
Mark Proctor
mproctor at codehaus.org
Thu Aug 18 10:48:00 EDT 2011
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 at codehaus.org
> <mailto:mproctor at 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 at lists.jboss.org <mailto:rules-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110818/462cc067/attachment.html
More information about the rules-dev
mailing list