8:28 a.m.
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
9:03 a.m.
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>
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
9:43 a.m.
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(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
9:48 a.m.
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
10:48 a.m.
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
11:15 a.m.
On 18/08/2011 16:48, Geoffrey De Smet wrote:
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?/*
This one would probably be
address by looking properly into a Lisp like
Macro system.
Mark
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
11:36 a.m.
My current decisions are| vs < I'm tempted ot try | so that it fits with
the filters, to avoid additional symbols.
I'm relatively happy with {name} and {...code...}, the prior can just be
considered a literal function call, where as the later is an anonymous
literal function.
I do want to resolve the switch statement. I don't like repeating 'from'
for each option:
$o : Object() from stream
( A() > [a] from $o or
B() > [b] from $o or
C() > [c] from $o )
Possibly a ; separation, similar to the planned accumulate changes.
case( Object() from stream;
A(),
B(),
C() )
btw the acc planned is
acc( CE*;
<func>*;
<guard>? )
acc( $o : Order();
$min : min( $o.value ),
$max : max($o.value);
$min > 100 && $max < 100 )
Mark
On 18/08/2011 15:48, Mark Proctor wrote:
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
4:35 p.m.
Hi Mark,
Since you're gathering 2 cents here and there I decided to add also mine
even if I am pretty sure that I am still missing the whole picture and
anyway at the moment I cannot see all the consequences of what I am going to
propose.
To tell you the truth I find the label syntax not very intuitive and I was
wondering if we could avoid it in some way. In the end what the 90% of the
users are asking for is just something like:
rule R
when
A()
then
do something
else
do something else
end
while we are going to give them something that is not exactly the same:
rule R
when
{notA} < A()
then
do something
then.notA
do something else
end
In particular I was thinking if we could keep the when ... then ... else
syntax that should be familiar to the biggest part of the users and at the
same time obtain a flexibility similar to the one provided by the labels
syntax. Probably we could do it with a kind of nested rules so, for
instance, the rule:
rule R1
when
{af} < A() > {at}
B()
then
DO
then.af
DO.af
then.at
DO.at
end
could be rewritten as it follows:
rule R1
when
B()
then
DO
rule R1A
when
A()
then
DO.at
else
DO.af
end
end
Of course the nested rule couldn't be used by the Drools engine as it is,
but we could implement a kind of "linearization" process at compile time
that translates it more or less as:
rule R1_1
when
A()
B()
then
DO
DO.at
end
rule R1_2
when
not A()
B()
then
DO
DO.af
end
In the same way the "or" example:
rule R1
when
( A() > {a1} or
B() > {b1} or
C() > {c1} )
D()
then
DO
then.a1
DO.a1
then.b1
DO.b1
then.c1
DO.c1
end
could be written as:
rule R1
when
D()
then
DO
rule R1A
when
A()
then
DO.a1
end
rule R1B
when
B()
then
DO.b1
end
rule R1C
when
C()
then
DO.c1
end
end
and then linearized at compile time in a similar way as I wrote before.
Once again I still haven't evaluated all the implications of my suggestion
neither I know if we can cover with it all the cases proposed by Mark. I am
pretty sure I am missing something important to be honest, but since we are
in a "brainstorming phase" I thought it could worth to consider it at least.
My 2 cents,
Mario
2:51 a.m.
It is one of the strengths of rule-based programming that the "procedural
forms" are kept at a minimum. Ideally, the LHS is an *expression *language,
with its expressions being evaluated according to the Engine's innate
mechanisms. Also, the clear separation of LHS conditions from RHS actions is
one of the more attractive features of reactive systems.
I think that the current LHS syntax needs only a minor extension. Without
syntactic sugar:
$bv: Boolean() from ce ( <LHS condition> )
This always succeeds, firing repeatedly as if it would for the LHS condition
being matched and setting $bv to true or firing once for no match with $bv
being false. Obviously,
Boolean( $bv: booleanValue == true ) from ce ( <LHS condition> )
is the same as just <LHS condition> and
Boolean( $bv: booleanValue == false ) from ce ( <LHS condition> )
is the same as not(<LHS condition>)
Notice that you could write the not-so-descriptive
rule cond when
$bv: Boolean() from ce (...)
then
if( $bv ){...} else {...}
end
but also the purely rule-based
rule cond when
$bv: Boolean() from ce (...)
then end
rule condTrue when
eval( $bv )
then
// RHS for match of LHS conditions
end
rule condTrue when
eval( ! $bv )
then
// RHS for no match of LHS conditions
end
More sophisticated patterns are possible with two or more booleans:
rule condA when $bva: Boolean() from ce (...) then end
rule condB extends condA when $bvb: Boolean() from ce (...) then end
Now an extension of condB can refer to both $bva and $bvb.
-W
On 18 August 2011 23:35, Mario Fusco <mario.fusco(a)gmail.com> wrote:
Hi Mark,
Since you're gathering 2 cents here and there I decided to add also mine
even if I am pretty sure that I am still missing the whole picture and
anyway at the moment I cannot see all the consequences of what I am going to
propose.
To tell you the truth I find the label syntax not very intuitive and I was
wondering if we could avoid it in some way. In the end what the 90% of the
users are asking for is just something like:
rule R
when
A()
then
do something
else
do something else
end
while we are going to give them something that is not exactly the same:
rule R
when
{notA} < A()
then
do something
then.notA
do something else
end
In particular I was thinking if we could keep the when ... then ... else
syntax that should be familiar to the biggest part of the users and at the
same time obtain a flexibility similar to the one provided by the labels
syntax. Probably we could do it with a kind of nested rules so, for
instance, the rule:
rule R1
when
{af} < A() > {at}
B()
then
DO
then.af
DO.af
then.at
DO.at
end
could be rewritten as it follows:
rule R1
when
B()
then
DO
rule R1A
when
A()
then
DO.at
else
DO.af
end
end
Of course the nested rule couldn't be used by the Drools engine as it is,
but we could implement a kind of "linearization" process at compile time
that translates it more or less as:
rule R1_1
when
A()
B()
then
DO
DO.at
end
rule R1_2
when
not A()
B()
then
DO
DO.af
end
In the same way the "or" example:
rule R1
when
( A() > {a1} or
B() > {b1} or
C() > {c1} )
D()
then
DO
then.a1
DO.a1
then.b1
DO.b1
then.c1
DO.c1
end
could be written as:
rule R1
when
D()
then
DO
rule R1A
when
A()
then
DO.a1
end
rule R1B
when
B()
then
DO.b1
end
rule R1C
when
C()
then
DO.c1
end
end
and then linearized at compile time in a similar way as I wrote before.
Once again I still haven't evaluated all the implications of my suggestion
neither I know if we can cover with it all the cases proposed by Mark. I am
pretty sure I am missing something important to be honest, but since we are
in a "brainstorming phase" I thought it could worth to consider it at least.
My 2 cents,
Mario
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:59 a.m.
I like Mario's proposal because I can actually read it.
Those special chars | < are gibberish to me.
The only reason we're not debating to use a new readable, intuitive
keyword, is because of the back-wards compatibility issues involved.
But using unreadable, unintuitive special char just for that, is
probably not a good idea.
I wonder if we reserve new keywords by prefix them with reserved special
char like "@"?
Then we can introduce as many keywords as we want without breaking
backwards compatibility.
Who's our target users for DRL authors?
A) Supersmart computer science guys
B) Blue collar Java programmers
C) Domain experts (= not programmers)
I 'd classify "{notA} < A()" as (given some time to learn it) readable
for A, but not for B and C.
Op 18-08-11 23:35, Mario Fusco schreef:
Hi Mark,
Since you're gathering 2 cents here and there I decided to add also
mine even if I am pretty sure that I am still missing the whole
picture and anyway at the moment I cannot see all the consequences of
what I am going to propose.
To tell you the truth I find the label syntax not very intuitive and I
was wondering if we could avoid it in some way. In the end what the
90% of the users are asking for is just something like:
rule R
when
A()
then
do something
else
do something else
end
while we are going to give them something that is not exactly the same:
rule R
when
{notA} < A()
then
do something
then.notA
do something else
end
In particular I was thinking if we could keep the when ... then ...
else syntax that should be familiar to the biggest part of the users
and at the same time obtain a flexibility similar to the one provided
by the labels syntax. Probably we could do it with a kind of nested
rules so, for instance, the rule:
rule R1
when
{af} < A() > {at}
B()
then
DO
then.af <http://then.af>
DO.af
then.at <http://then.at>
DO.at
end
could be rewritten as it follows:
rule R1
when
B()
then
DO
rule R1A
when
A()
then
DO.at
else
DO.af
end
end
Of course the nested rule couldn't be used by the Drools engine as it
is, but we could implement a kind of "linearization" process at
compile time that translates it more or less as:
rule R1_1
when
A()
B()
then
DO
DO.at
end
rule R1_2
when
not A()
B()
then
DO
DO.af
end
In the same way the "or" example:
rule R1
when
( A() > {a1} or
B() > {b1} or
C() > {c1} )
D()
then
DO
then.a1
DO.a1
then.b1
DO.b1
then.c1
DO.c1
end
could be written as:
rule R1
when
D()
then
DO
rule R1A
when
A()
then
DO.a1
end
rule R1B
when
B()
then
DO.b1
end
rule R1C
when
C()
then
DO.c1
end
end
and then linearized at compile time in a similar way as I wrote before.
Once again I still haven't evaluated all the implications of my
suggestion neither I know if we can cover with it all the cases
proposed by Mark. I am pretty sure I am missing something important to
be honest, but since we are in a "brainstorming phase" I thought it
could worth to consider it at least.
My 2 cents,
Mario
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
7:25 a.m.
I’m also struggling to read and understand the original syntax and I don’t think the rest
of my team would realise what was happening if I wrote something like that.
Some form of nested rules with a when … then when … else when …then … else … then … end
type syntax will be much easier for people to understand what is happening without having
to understand much of the syntax. Some form of nesting will be needed to identify the
scoping of matches.
The other alternative is to add the concept of a named condition
condition “ABC” when a : A() … end
rules would be able to reference conditions and access the bindings defined within there
scope, this would allow you to write
rule “A”
when
condition “ABC”
then
print a; //a is bound in the condition
end
and for the else
rule “not A”
when
not condition “ABC”
and
multiple conditions could be used allowing the equivalent functionality of many else when
combinations but with easier to read rules.
Thomas
From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On
Behalf Of Geoffrey De Smet
Sent: 19 August 2011 13:00
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] else
I like Mario's proposal because I can actually read it.
Those special chars | < are gibberish to me.
The only reason we're not debating to use a new readable, intuitive keyword, is
because of the back-wards compatibility issues involved.
But using unreadable, unintuitive special char just for that, is probably not a good
idea.
I wonder if we reserve new keywords by prefix them with reserved special char like
"@"?
Then we can introduce as many keywords as we want without breaking backwards
compatibility.
Who's our target users for DRL authors?
A) Supersmart computer science guys
B) Blue collar Java programmers
C) Domain experts (= not programmers)
I 'd classify "{notA} < A()" as (given some time to learn it) readable
for A, but not for B and C.
Op 18-08-11 23:35, Mario Fusco schreef:
Hi Mark,
Since you're gathering 2 cents here and there I decided to add also mine even if I am
pretty sure that I am still missing the whole picture and anyway at the moment I cannot
see all the consequences of what I am going to propose.
To tell you the truth I find the label syntax not very intuitive and I was wondering if we
could avoid it in some way. In the end what the 90% of the users are asking for is just
something like:
rule R
when
A()
then
do something
else
do something else
end
while we are going to give them something that is not exactly the same:
rule R
when
{notA} < A()
then
do something
then.notA
do something else
end
In particular I was thinking if we could keep the when ... then ... else syntax that
should be familiar to the biggest part of the users and at the same time obtain a
flexibility similar to the one provided by the labels syntax. Probably we could do it with
a kind of nested rules so, for instance, the rule:
rule R1
when
{af} < A() > {at}
B()
then
DO
then.af<http://then.af>
DO.af
then.at<http://then.at>
DO.at
end
could be rewritten as it follows:
rule R1
when
B()
then
DO
rule R1A
when
A()
then
DO.at
else
DO.af
end
end
Of course the nested rule couldn't be used by the Drools engine as it is, but we could
implement a kind of "linearization" process at compile time that translates it
more or less as:
rule R1_1
when
A()
B()
then
DO
DO.at
end
rule R1_2
when
not A()
B()
then
DO
DO.af
end
In the same way the "or" example:
rule R1
when
( A() > {a1} or
B() > {b1} or
C() > {c1} )
D()
then
DO
then.a1
DO.a1
then.b1
DO.b1
then.c1
DO.c1
end
could be written as:
rule R1
when
D()
then
DO
rule R1A
when
A()
then
DO.a1
end
rule R1B
when
B()
then
DO.b1
end
rule R1C
when
C()
then
DO.c1
end
end
and then linearized at compile time in a similar way as I wrote before.
Once again I still haven't evaluated all the implications of my suggestion neither I
know if we can cover with it all the cases proposed by Mark. I am pretty sure I am missing
something important to be honest, but since we are in a "brainstorming phase" I
thought it could worth to consider it at least.
My 2 cents,
Mario
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
7:56 a.m.
I got the same feeling that Geoffrey had about readability.
We added "from" its really easy to get, why not add "else".
when
Person( name == "darth" ) else [darthIsMissing]
A()
then
....
then.darthIsMissing
log("Darth was never found");
end
or
when
Person( name == "darth" ) else { log("Darth was never found");
}
A()
then
....
end
"Inline then" could be done with inner rules. Similar to what Mario suggested.
rule "Handle Login"
when
$loginRequest :LoginRequest()
AuthorizedUsers( list contains $loginRequest.user ) else [unsuccessfulLoginAttempt]
inner rule "Check if Admin"
$p :AdminRights( user == $loginRequest.user )
then
showAdminMenu();
end
then
logInUser( $loginRequest.user );
then.unsuccessfulLoginAttempt
log( "There was and unsuccessful login attempt with the user name " +
$loginRequest.user.name );
end
Toni
On Aug 19, 2011, at 2:59 PM, Geoffrey De Smet wrote:
I like Mario's proposal because I can actually read it.
Those special chars | < are gibberish to me.
The only reason we're not debating to use a new readable, intuitive keyword, is
because of the back-wards compatibility issues involved.
But using unreadable, unintuitive special char just for that, is probably not a good
idea.
I wonder if we reserve new keywords by prefix them with reserved special char like
"@"?
Then we can introduce as many keywords as we want without breaking backwards
compatibility.
Who's our target users for DRL authors?
A) Supersmart computer science guys
B) Blue collar Java programmers
C) Domain experts (= not programmers)
I 'd classify "{notA} < A()" as (given some time to learn it) readable
for A, but not for B and C.
Op 18-08-11 23:35, Mario Fusco schreef:
>
> Hi Mark,
>
> Since you're gathering 2 cents here and there I decided to add also mine even if
I am pretty sure that I am still missing the whole picture and anyway at the moment I
cannot see all the consequences of what I am going to propose.
>
> To tell you the truth I find the label syntax not very intuitive and I was wondering
if we could avoid it in some way. In the end what the 90% of the users are asking for is
just something like:
>
> rule R
> when
> A()
> then
> do something
> else
> do something else
> end
>
> while we are going to give them something that is not exactly the same:
>
> rule R
> when
> {notA} < A()
> then
> do something
> then.notA
> do something else
> end
>
> In particular I was thinking if we could keep the when ... then ... else syntax that
should be familiar to the biggest part of the users and at the same time obtain a
flexibility similar to the one provided by the labels syntax. Probably we could do it with
a kind of nested rules so, for instance, the rule:
>
> rule R1
> when
> {af} < A() > {at}
> B()
> then
> DO
> then.af
> DO.af
> then.at
> DO.at
> end
>
> could be rewritten as it follows:
>
> rule R1
> when
> B()
> then
> DO
> rule R1A
> when
> A()
> then
> DO.at
> else
> DO.af
> end
> end
>
> Of course the nested rule couldn't be used by the Drools engine as it is, but we
could implement a kind of "linearization" process at compile time that
translates it more or less as:
>
> rule R1_1
> when
> A()
> B()
> then
> DO
> DO.at
> end
>
> rule R1_2
> when
> not A()
> B()
> then
> DO
> DO.af
> end
>
> In the same way the "or" example:
>
> rule R1
> when
> ( A() > {a1} or
> B() > {b1} or
> C() > {c1} )
> D()
> then
> DO
> then.a1
> DO.a1
> then.b1
> DO.b1
> then.c1
> DO.c1
> end
>
> could be written as:
>
> rule R1
> when
> D()
> then
> DO
> rule R1A
> when
> A()
> then
> DO.a1
> end
> rule R1B
> when
> B()
> then
> DO.b1
> end
> rule R1C
> when
> C()
> then
> DO.c1
> end
> end
>
> and then linearized at compile time in a similar way as I wrote before.
>
> Once again I still haven't evaluated all the implications of my suggestion
neither I know if we can cover with it all the cases proposed by Mark. I am pretty sure I
am missing something important to be honest, but since we are in a "brainstorming
phase" I thought it could worth to consider it at least.
>
> My 2 cents,
> Mario
>
>
> _______________________________________________
> 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
6:34 p.m.
For further info, this is what ilog do. They only allow an implicit
"else" on the last "evaluate" expression. Which while simple is quite
restrictive.:
http://publib.boulder.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=/c...
rule ruleName {
when
{conditioni evaluate (expression)}
then
{[action1...actionm]}
else
{[action1 ...actionp]}
};
OPSJ is the only engine that i know of that uses labels:
x.name == obj,
x.weight == "light",
x.location != g.location);
mky: monkey;
[4] (mky.holds == obj);
} do {
makegoal("walkto", loc);
} else( 4 ) {
makegoal("holds", obj);
}
Although I would encourage people to think beyond simple "if/else", the
proposal I put forward would allow for tree like data flows for signal
processing - which will map very nicely to GUI tooling.
Mark
On 19/08/2011 13:56, Toni Rikkola wrote:
I got the same feeling that Geoffrey had about readability.
We added "from" its really easy to get, why not add "else".
when
Person( name == "darth" ) else [darthIsMissing]
A()
then
....
then.darthIsMissing
log("Darth was never found");
end
or
when
Person( name == "darth" ) else { log("Darth was never found");
}
A()
then
....
end
"Inline then" could be done with inner rules. Similar to what Mario
suggested.
rule "Handle Login"
when
$loginRequest :LoginRequest()
AuthorizedUsers( list contains $loginRequest.user ) else
[unsuccessfulLoginAttempt]
inner rule "Check if Admin"
$p :AdminRights( user == $loginRequest.user )
then
showAdminMenu();
end
then
logInUser( $loginRequest.user );
then.unsuccessfulLoginAttempt
log( "There was and unsuccessful login attempt with the user name
" + $loginRequest.user.name );
end
Toni
On Aug 19, 2011, at 2:59 PM, Geoffrey De Smet wrote:
> I like Mario's proposal because I can actually read it.
> Those special chars | < are gibberish to me.
>
> The only reason we're not debating to use a new readable, intuitive
> keyword, is because of the back-wards compatibility issues involved.
> But using unreadable, unintuitive special char just for that, is
> probably not a good idea.
> I wonder if we reserve new keywords by prefix them with reserved
> special char like "@"?
> Then we can introduce as many keywords as we want without breaking
> backwards compatibility.
>
> Who's our target users for DRL authors?
> A) Supersmart computer science guys
> B) Blue collar Java programmers
> C) Domain experts (= not programmers)
>
> I 'd classify "{notA} < A()" as (given some time to learn it)
> readable for A, but not for B and C.
>
> Op 18-08-11 23:35, Mario Fusco schreef:
>> Hi Mark,
>>
>> Since you're gathering 2 cents here and there I decided to add also
>> mine even if I am pretty sure that I am still missing the whole
>> picture and anyway at the moment I cannot see all the consequences
>> of what I am going to propose.
>>
>> To tell you the truth I find the label syntax not very intuitive and
>> I was wondering if we could avoid it in some way. In the end what
>> the 90% of the users are asking for is just something like:
>>
>> rule R
>> when
>> A()
>> then
>> do something
>> else
>> do something else
>> end
>>
>> while we are going to give them something that is not exactly the same:
>>
>> rule R
>> when
>> {notA} < A()
>> then
>> do something
>> then.notA
>> do something else
>> end
>>
>> In particular I was thinking if we could keep the when ... then ...
>> else syntax that should be familiar to the biggest part of the users
>> and at the same time obtain a flexibility similar to the one
>> provided by the labels syntax. Probably we could do it with a kind
>> of nested rules so, for instance, the rule:
>>
>> rule R1
>> when
>> {af} < A() > {at}
>> B()
>> then
>> DO
>> then.af <http://then.af/>
>> DO.af
>> then.at <http://then.at/>
>> DO.at <http://DO.at>
>> end
>>
>> could be rewritten as it follows:
>>
>> rule R1
>> when
>> B()
>> then
>> DO
>> rule R1A
>> when
>> A()
>> then
>> DO.at <http://DO.at>
>> else
>> DO.af
>> end
>> end
>>
>> Of course the nested rule couldn't be used by the Drools engine as
>> it is, but we could implement a kind of "linearization" process at
>> compile time that translates it more or less as:
>>
>> rule R1_1
>> when
>> A()
>> B()
>> then
>> DO
>> DO.at <http://DO.at>
>> end
>>
>> rule R1_2
>> when
>> not A()
>> B()
>> then
>> DO
>> DO.af
>> end
>>
>> In the same way the "or" example:
>>
>> rule R1
>> when
>> ( A() > {a1} or
>> B() > {b1} or
>> C() > {c1} )
>> D()
>> then
>> DO
>> then.a1
>> DO.a1
>> then.b1
>> DO.b1
>> then.c1
>> DO.c1
>> end
>>
>> could be written as:
>>
>> rule R1
>> when
>> D()
>> then
>> DO
>> rule R1A
>> when
>> A()
>> then
>> DO.a1
>> end
>> rule R1B
>> when
>> B()
>> then
>> DO.b1
>> end
>> rule R1C
>> when
>> C()
>> then
>> DO.c1
>> end
>> end
>>
>> and then linearized at compile time in a similar way as I wrote before.
>>
>> Once again I still haven't evaluated all the implications of my
>> suggestion neither I know if we can cover with it all the cases
>> proposed by Mark. I am pretty sure I am missing something important
>> to be honest, but since we are in a "brainstorming phase" I thought
>> it could worth to consider it at least.
>>
>> My 2 cents,
>> Mario
>>
>>
>> _______________________________________________
>> 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 <mailto:rules-dev@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
2:05 p.m.
I like Mario's suggestion.
Use of a switch statement could also be an option (to muddy the waters
further):-
rule R1
when
D()
switch
A()
then
a1
B()
then
b1
C()
then
c1
switch
then
d1
end
I definitely don't like the ">" "{..}" notation.
Cheers,
Mike
On 20 August 2011 00:34, Mark Proctor <mproctor(a)codehaus.org> wrote:
For further info, this is what ilog do. They only allow an implicit
"else"
on the last "evaluate" expression. Which while simple is quite restrictive.:
http://publib.boulder.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=/c...
rule ruleName { when
{conditioni evaluate (expression)} then
{[action1 ... actionm]}
else
{[action1 ... actionp]}
};
OPSJ is the only engine that i know of that uses labels:
x.name == obj,
x.weight == "light",
x.location != g.location);
mky: monkey;
[4] (mky.holds == obj);
} do {
makegoal("walkto", loc);
} else( 4 ) {
makegoal("holds", obj);
}
Although I would encourage people to think beyond simple "if/else", the
proposal I put forward would allow for tree like data flows for signal
processing - which will map very nicely to GUI tooling.
Mark
On 19/08/2011 13:56, Toni Rikkola wrote:
I got the same feeling that Geoffrey had about readability.
We added "from" its really easy to get, why not add "else".
when
Person( name == "darth" ) else [darthIsMissing]
A()
then
....
then.darthIsMissing
log("Darth was never found");
end
or
when
Person( name == "darth" ) else { log("Darth was never found");
}
A()
then
....
end
"Inline then" could be done with inner rules. Similar to what Mario
suggested.
rule "Handle Login"
when
$loginRequest :LoginRequest()
AuthorizedUsers( list contains $loginRequest.user ) else
[unsuccessfulLoginAttempt]
inner rule "Check if Admin"
$p :AdminRights( user == $loginRequest.user )
then
showAdminMenu();
end
then
logInUser( $loginRequest.user );
then.unsuccessfulLoginAttempt
log( "There was and unsuccessful login attempt with the user name " + $
loginRequest.user.name );
end
Toni
On Aug 19, 2011, at 2:59 PM, Geoffrey De Smet wrote:
I like Mario's proposal because I can actually read it.
Those special chars | < are gibberish to me.
The only reason we're not debating to use a new readable, intuitive
keyword, is because of the back-wards compatibility issues involved.
But using unreadable, unintuitive special char just for that, is probably
not a good idea.
I wonder if we reserve new keywords by prefix them with reserved special
char like "@"?
Then we can introduce as many keywords as we want without breaking
backwards compatibility.
Who's our target users for DRL authors?
A) Supersmart computer science guys
B) Blue collar Java programmers
C) Domain experts (= not programmers)
I 'd classify "{notA} < A()" as (given some time to learn it) readable
for
A, but not for B and C.
Op 18-08-11 23:35, Mario Fusco schreef:
Hi Mark,
Since you're gathering 2 cents here and there I decided to add also mine
even if I am pretty sure that I am still missing the whole picture and
anyway at the moment I cannot see all the consequences of what I am going to
propose.
To tell you the truth I find the label syntax not very intuitive and I was
wondering if we could avoid it in some way. In the end what the 90% of the
users are asking for is just something like:
rule R
when
A()
then
do something
else
do something else
end
while we are going to give them something that is not exactly the same:
rule R
when
{notA} < A()
then
do something
then.notA
do something else
end
In particular I was thinking if we could keep the when ... then ... else
syntax that should be familiar to the biggest part of the users and at the
same time obtain a flexibility similar to the one provided by the labels
syntax. Probably we could do it with a kind of nested rules so, for
instance, the rule:
rule R1
when
{af} < A() > {at}
B()
then
DO
then.af
DO.af
then.at
DO.at
end
could be rewritten as it follows:
rule R1
when
B()
then
DO
rule R1A
when
A()
then
DO.at
else
DO.af
end
end
Of course the nested rule couldn't be used by the Drools engine as it is,
but we could implement a kind of "linearization" process at compile time
that translates it more or less as:
rule R1_1
when
A()
B()
then
DO
DO.at
end
rule R1_2
when
not A()
B()
then
DO
DO.af
end
In the same way the "or" example:
rule R1
when
( A() > {a1} or
B() > {b1} or
C() > {c1} )
D()
then
DO
then.a1
DO.a1
then.b1
DO.b1
then.c1
DO.c1
end
could be written as:
rule R1
when
D()
then
DO
rule R1A
when
A()
then
DO.a1
end
rule R1B
when
B()
then
DO.b1
end
rule R1C
when
C()
then
DO.c1
end
end
and then linearized at compile time in a similar way as I wrote before.
Once again I still haven't evaluated all the implications of my suggestion
neither I know if we can cover with it all the cases proposed by Mark. I am
pretty sure I am missing something important to be honest, but since we are
in a "brainstorming phase" I thought it could worth to consider it at least.
My 2 cents,
Mario
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://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
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://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
7:45 a.m.
On 20 August 2011 21:05, Michael Anstis <michael.anstis(a)gmail.com> wrote:
I like Mario's suggestion.
Use of a switch statement could also be an option (to muddy the waters
further):-
Any good reason for calling a "switch" what is usually an if/elsif? Also,
would the branches have an implied "break"? Or should any number of branches
fire for a single match of the CEs preceding the "switch"? If so, what if
"a1" (in the example) retracts tha fact matching "D()", and then
"a2" needs
to be executed?
Anybody making proposals is cordially invited not just to provide a syntax
silhouette.
Thank you
-W
rule R1
when
D()
switch
A()
then
a1
B()
then
b1
C()
then
c1
switch
then
d1
end
I definitely don't like the ">" "{..}" notation.
Cheers,
Mike
On 20 August 2011 00:34, Mark Proctor <mproctor(a)codehaus.org> wrote:
> For further info, this is what ilog do. They only allow an implicit
> "else" on the last "evaluate" expression. Which while simple is
quite
> restrictive.:
>
>
http://publib.boulder.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=/c...
>
> rule ruleName { when
> {conditioni evaluate (expression)} then
> {[action1 ... actionm]}
> else
> {[action1 ... actionp]}
> };
>
> OPSJ is the only engine that i know of that uses labels:
> x.name == obj,
> x.weight == "light",
> x.location != g.location);
> mky: monkey;
> [4] (mky.holds == obj);
> } do {
> makegoal("walkto", loc);
> } else( 4 ) {
> makegoal("holds", obj);
> }
>
> Although I would encourage people to think beyond simple "if/else", the
> proposal I put forward would allow for tree like data flows for signal
> processing - which will map very nicely to GUI tooling.
>
> Mark
>
>
>
> On 19/08/2011 13:56, Toni Rikkola wrote:
>
> I got the same feeling that Geoffrey had about readability.
>
> We added "from" its really easy to get, why not add "else".
>
> when
> Person( name == "darth" ) else [darthIsMissing]
> A()
> then
> ....
> then.darthIsMissing
> log("Darth was never found");
> end
>
> or
>
> when
> Person( name == "darth" ) else { log("Darth was never
found"); }
> A()
> then
> ....
> end
>
> "Inline then" could be done with inner rules. Similar to what Mario
> suggested.
>
> rule "Handle Login"
> when
> $loginRequest :LoginRequest()
> AuthorizedUsers( list contains $loginRequest.user ) else
> [unsuccessfulLoginAttempt]
>
> inner rule "Check if Admin"
> $p :AdminRights( user == $loginRequest.user )
> then
> showAdminMenu();
> end
>
> then
> logInUser( $loginRequest.user );
>
> then.unsuccessfulLoginAttempt
> log( "There was and unsuccessful login attempt with the user name " +
> $loginRequest.user.name );
> end
>
> Toni
>
> On Aug 19, 2011, at 2:59 PM, Geoffrey De Smet wrote:
>
> I like Mario's proposal because I can actually read it.
> Those special chars | < are gibberish to me.
>
> The only reason we're not debating to use a new readable, intuitive
> keyword, is because of the back-wards compatibility issues involved.
> But using unreadable, unintuitive special char just for that, is probably
> not a good idea.
> I wonder if we reserve new keywords by prefix them with reserved special
> char like "@"?
> Then we can introduce as many keywords as we want without breaking
> backwards compatibility.
>
> Who's our target users for DRL authors?
> A) Supersmart computer science guys
> B) Blue collar Java programmers
> C) Domain experts (= not programmers)
>
> I 'd classify "{notA} < A()" as (given some time to learn it)
readable for
> A, but not for B and C.
>
> Op 18-08-11 23:35, Mario Fusco schreef:
>
> Hi Mark,
>
> Since you're gathering 2 cents here and there I decided to add also mine
> even if I am pretty sure that I am still missing the whole picture and
> anyway at the moment I cannot see all the consequences of what I am going to
> propose.
>
> To tell you the truth I find the label syntax not very intuitive and I was
> wondering if we could avoid it in some way. In the end what the 90% of the
> users are asking for is just something like:
>
> rule R
> when
> A()
> then
> do something
> else
> do something else
> end
>
> while we are going to give them something that is not exactly the same:
>
> rule R
> when
> {notA} < A()
> then
> do something
> then.notA
> do something else
> end
>
> In particular I was thinking if we could keep the when ... then ... else
> syntax that should be familiar to the biggest part of the users and at the
> same time obtain a flexibility similar to the one provided by the labels
> syntax. Probably we could do it with a kind of nested rules so, for
> instance, the rule:
>
> rule R1
> when
> {af} < A() > {at}
> B()
> then
> DO
> then.af
> DO.af
> then.at
> DO.at
> end
>
> could be rewritten as it follows:
>
> rule R1
> when
> B()
> then
> DO
> rule R1A
> when
> A()
> then
> DO.at
> else
> DO.af
> end
> end
>
> Of course the nested rule couldn't be used by the Drools engine as it is,
> but we could implement a kind of "linearization" process at compile time
> that translates it more or less as:
>
> rule R1_1
> when
> A()
> B()
> then
> DO
> DO.at
> end
>
> rule R1_2
> when
> not A()
> B()
> then
> DO
> DO.af
> end
>
> In the same way the "or" example:
>
> rule R1
> when
> ( A() > {a1} or
> B() > {b1} or
> C() > {c1} )
> D()
> then
> DO
> then.a1
> DO.a1
> then.b1
> DO.b1
> then.c1
> DO.c1
> end
>
> could be written as:
>
> rule R1
> when
> D()
> then
> DO
> rule R1A
> when
> A()
> then
> DO.a1
> end
> rule R1B
> when
> B()
> then
> DO.b1
> end
> rule R1C
> when
> C()
> then
> DO.c1
> end
> end
>
> and then linearized at compile time in a similar way as I wrote before.
>
> Once again I still haven't evaluated all the implications of my suggestion
> neither I know if we can cover with it all the cases proposed by Mark. I am
> pretty sure I am missing something important to be honest, but since we are
> in a "brainstorming phase" I thought it could worth to consider it at
least.
>
> My 2 cents,
> Mario
>
>
> _______________________________________________
> rules-dev mailing
listrules-dev@lists.jboss.orghttps://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
>
>
>
>
> _______________________________________________
> rules-dev mailing
listrules-dev@lists.jboss.orghttps://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
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8:06 a.m.
On 21/08/2011 13:45, Wolfgang Laun wrote:
On 20 August 2011 21:05, Michael Anstis <michael.anstis(a)gmail.com
<mailto:michael.anstis@gmail.com>> wrote:
I like Mario's suggestion.
Use of a switch statement could also be an option (to muddy the
waters further):-
Any good reason for calling a "switch" what is usually an if/elsif?
Also, would the branches have an implied "break"? Or should any number
of branches fire for a single match of the CEs preceding the "switch"?
If so, what if "a1" (in the example) retracts tha fact matching
"D()",
and then "a2" needs to be executed?
Anybody making proposals is cordially invited not just to provide a
syntax silhouette.
Thank you
-W
rule R1
when
D()
switch
A()
then
a1
B()
then
b1
C()
then
c1
switch
then
d1
end
I definitely don't like the ">" "{..}" notation.
Cheers,
Mike
On 20 August 2011 00:34, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
For further info, this is what ilog do. They only allow an
implicit "else" on the last "evaluate" expression. Which
while
simple is quite restrictive.:
http://publib.boulder.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=/c...
rule ruleName {
when
{conditioni evaluate (expression)}
then
{[action1...actionm]}
else
{[action1 ...actionp]}
};
OPSJ is the only engine that i know of that uses labels:
x.name <http://x.name> == obj,
x.weight == "light",
x.location != g.location);
mky: monkey;
[4] (mky.holds == obj);
} do {
makegoal("walkto", loc);
} else( 4 ) {
makegoal("holds", obj);
}
Although I would encourage people to think beyond simple
"if/else", the proposal I put forward would allow for tree
like data flows for signal processing - which will map very
nicely to GUI tooling.
I proposed something like this, based around the OPSJ labels approach.
It helps if you think of a "then" block as a function literal and the
{func_lit_name} as an inline code fragment that calls the function literal.
So this:
$o : Object() from stream
( A() | {a} from $o or
B() | {b} from $o or
C() | {c} from $o )
becomes:
case( Object() from stream; // notice the semi colon to separate the
object that specifies the default 'from'
A() | {a},
B() | {b},
C() | {c} )
then
...
then.a
....
then.b
....
then.c
end.
The above would currently work like 'or'. All matching branches would
activate. I thought about a short cut or. I think the answer there is to
build a prolog like 'cut' operator, which we need for queries anyway.
However adding 'cut' is far from trivial as it'll involve substantial
changes to the current Rete algorithm, but assuming we could eventually
make those changes, maybe something like:
case( Object() from stream; // notice the semi colon to separate the
object that specifies the default 'from'
A() | {a} | cut,
B() | {b}| cut,
C() | {c} | cut)
When thinking about the | symbol, think of unix pipes. The pipe
indicates to filter the output of the pattern, the pipe allows chaining
of these "filters", much like unix, such that the propagation then goe
sfrom the labelled "functional literal" to the cut CE. I plan to allow
the | symbol to be used to integrate user pluggable filters, such as
"distinct". The following will filter all A() matches using a distinct
filter, making sure only distinct matches are execute by the "a"
functional literal. The cut symbpol ensures that only the first match is
found, all other matches (join attempts) will be stopped - including
those in the various 'or' branches if they exist.
A() | distinct | {a} | cut
For consistency we will allow time windows to be used as filters. Over
the last 30 seconds find the distinct A and activate on it, but do not
find any more matches after that.
A() | time.window(30s) | distinct | {a} | cut.
Hopefully that shows why I want to introduce a general purpose "|" pipe
symbol for connecting "filters" and use that in a very generic way.
Rather than introducing various different keywords.
This syntax is not aimed at business users, who will be using the guided
editor anyway and the verbalisations that come with that, even more so
true once we start to add natural language. So I'm not overly keen to
restrict or limit things for a group of people won't use the low level
syntax anyway.
Mark
Mark
On 19/08/2011 13:56, Toni Rikkola wrote:
> I got the same feeling that Geoffrey had about readability.
>
> We added "from" its really easy to get, why not add
"else".
>
> when
> Person( name == "darth" ) else [darthIsMissing]
> A()
> then
> ....
> then.darthIsMissing
> log("Darth was never found");
> end
>
> or
>
> when
> Person( name == "darth" ) else { log("Darth was never
> found"); }
> A()
> then
> ....
> end
>
> "Inline then" could be done with inner rules. Similar to what
> Mario suggested.
>
> rule "Handle Login"
> when
> $loginRequest :LoginRequest()
> AuthorizedUsers( list contains $loginRequest.user ) else
> [unsuccessfulLoginAttempt]
>
> inner rule "Check if Admin"
> $p :AdminRights( user == $loginRequest.user )
> then
> showAdminMenu();
> end
>
> then
> logInUser( $loginRequest.user );
>
> then.unsuccessfulLoginAttempt
> log( "There was and unsuccessful login attempt with the
> user name " + $loginRequest.user.name
> <http://loginRequest.user.name> );
> end
>
> Toni
>
> On Aug 19, 2011, at 2:59 PM, Geoffrey De Smet wrote:
>
>> I like Mario's proposal because I can actually read it.
>> Those special chars | < are gibberish to me.
>>
>> The only reason we're not debating to use a new readable,
>> intuitive keyword, is because of the back-wards
>> compatibility issues involved.
>> But using unreadable, unintuitive special char just for
>> that, is probably not a good idea.
>> I wonder if we reserve new keywords by prefix them with
>> reserved special char like "@"?
>> Then we can introduce as many keywords as we want without
>> breaking backwards compatibility.
>>
>> Who's our target users for DRL authors?
>> A) Supersmart computer science guys
>> B) Blue collar Java programmers
>> C) Domain experts (= not programmers)
>>
>> I 'd classify "{notA} < A()" as (given some time to
learn
>> it) readable for A, but not for B and C.
>>
>> Op 18-08-11 23:35, Mario Fusco schreef:
>>> Hi Mark,
>>>
>>> Since you're gathering 2 cents here and there I decided to
>>> add also mine even if I am pretty sure that I am still
>>> missing the whole picture and anyway at the moment I cannot
>>> see all the consequences of what I am going to propose.
>>>
>>> To tell you the truth I find the label syntax not very
>>> intuitive and I was wondering if we could avoid it in some
>>> way. In the end what the 90% of the users are asking for is
>>> just something like:
>>>
>>> rule R
>>> when
>>> A()
>>> then
>>> do something
>>> else
>>> do something else
>>> end
>>>
>>> while we are going to give them something that is not
>>> exactly the same:
>>>
>>> rule R
>>> when
>>> {notA} < A()
>>> then
>>> do something
>>> then.notA
>>> do something else
>>> end
>>>
>>> In particular I was thinking if we could keep the when ...
>>> then ... else syntax that should be familiar to the biggest
>>> part of the users and at the same time obtain a flexibility
>>> similar to the one provided by the labels syntax. Probably
>>> we could do it with a kind of nested rules so, for
>>> instance, the rule:
>>>
>>> rule R1
>>> when
>>> {af} < A() > {at}
>>> B()
>>> then
>>> DO
>>> then.af <http://then.af/>
>>> DO.af
>>> then.at <http://then.at/>
>>> DO.at <http://DO.at>
>>> end
>>>
>>> could be rewritten as it follows:
>>>
>>> rule R1
>>> when
>>> B()
>>> then
>>> DO
>>> rule R1A
>>> when
>>> A()
>>> then
>>> DO.at <http://DO.at>
>>> else
>>> DO.af
>>> end
>>> end
>>>
>>> Of course the nested rule couldn't be used by the Drools
>>> engine as it is, but we could implement a kind of
>>> "linearization" process at compile time that translates it
>>> more or less as:
>>>
>>> rule R1_1
>>> when
>>> A()
>>> B()
>>> then
>>> DO
>>> DO.at <http://DO.at>
>>> end
>>>
>>> rule R1_2
>>> when
>>> not A()
>>> B()
>>> then
>>> DO
>>> DO.af
>>> end
>>>
>>> In the same way the "or" example:
>>>
>>> rule R1
>>> when
>>> ( A() > {a1} or
>>> B() > {b1} or
>>> C() > {c1} )
>>> D()
>>> then
>>> DO
>>> then.a1
>>> DO.a1
>>> then.b1
>>> DO.b1
>>> then.c1
>>> DO.c1
>>> end
>>>
>>> could be written as:
>>>
>>> rule R1
>>> when
>>> D()
>>> then
>>> DO
>>> rule R1A
>>> when
>>> A()
>>> then
>>> DO.a1
>>> end
>>> rule R1B
>>> when
>>> B()
>>> then
>>> DO.b1
>>> end
>>> rule R1C
>>> when
>>> C()
>>> then
>>> DO.c1
>>> end
>>> end
>>>
>>> and then linearized at compile time in a similar way as I
>>> wrote before.
>>>
>>> Once again I still haven't evaluated all the implications
>>> of my suggestion neither I know if we can cover with it all
>>> the cases proposed by Mark. I am pretty sure I am missing
>>> something important to be honest, but since we are in a
>>> "brainstorming phase" I thought it could worth to consider
>>> it at least.
>>>
>>> My 2 cents,
>>> Mario
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@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 <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@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
4873
days inactive
4876
days old
15 comments
8 participants
participants (8)
-
Edson Tirelli -
Geoffrey De Smet -
Mario Fusco -
Mark Proctor -
Michael Anstis -
Swindells, Thomas -
Toni Rikkola -
Wolfgang Laun