[rules-dev] else
Mark Proctor
mproctor at codehaus.org
Thu Aug 18 10:43:54 EDT 2011
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?
no plans for unlabelled "else". "otherwise" is something different.
>
> 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.
The labelled consequencei is necessary for compact case statements,
which is very common for signal processing type problems, otherwise you
need to generate a large number of rules with small variations which is
harder to read and maintain. This "case" type of construct is at the
heart of erlang.
o : Object() from stream
(or A( field1 == "1" ) > {a1} from o
A( field1 == "2" ) > {a2} from o
B( field1 == "3 ) > {b1} from o
B( field2 == "5", field 3 == 6 ) > {b2} ) from o
http://www.erlang.org/doc/reference_manual/expressions.html#id75991
When can do this one step at a time, no need for a big bang. Each
proposal is an iterative improvement on the last. What i want to make
sure is we have done the design through to completion and considered all
edge cases, so as to avoid a dead end in the syntax should we add it
later. Last thing i want to do is think in one years time "oh it would
be nice to add this but we can't because of a syntax choice we made
earlier and we didn't want to think about more complex use cases as we
assumed they would never be necessary".
the only issue with {label} as opposed to [label] is what do we chose
for when we want inline code rather than label. I guess we can say
{label} will call a function literal if it exists, otherwise it attempts
to be evaluated as an expression.
Mark
>
> 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/2248b56f/attachment-0001.html
More information about the rules-dev
mailing list