3:38 p.m.
Don't have any antlr experience, but I'd say that would be a very valuable
addition - probably more BAs would be able to pick it up this way (without
having to fallback on custom DSL)
Vlad
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: 20 March 2007 15:54
To: Rules Dev List
Subject: Re: [rules-dev] sugar
Could also allow:
Cheese( name = Person( location == "london").favourCheese )
Can also use this to constrain on the fact itself, instead of just a field:
Person( cheese = Cheese( type == "stilton ) )
This could be use in config options:
Call( duration < CallConf().minDuration )
But as Edson pointed out it is open to abuse and misunderstanding, how
long till people do:
Call( duration < CallConf().maxDuration, duration > CallConf().maxDuration )
Which is more like doing the following which has cross product issues:
CallConf( $maxDuration1 : maxDuration )
CallConf( $maxDuration2 : maxDuration )
Call( duration < ,$maxDuration1 duration > $maxDuration2 )
Mark
Mark Proctor wrote:
I've been thinking of an idea to make rules more expressive, its
just
syntax sugar at the parser level, but thought i'd ask feedback - if
anyone with antlr skills wants to make this work, let us know :)
Instead of doing:
$p : Person($favouriteCheese : favouriteCheese )
Cheese( name == $favouriteCheese )
We should allow the following:
$p : Person()
Cheese( name == $p.favouriteCheese )
We could take this further and in places where a pattern is not used
elsewhere allow:
Cheese( name == Person().favouriteCheese )
Mark
_______________________________________________
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:26 p.m.
New subject: sugar
I think it is a dangerous move.
It is easy for users to understand that each pattern matches a fact:
A( ... )
B( ... )
C( ... )
If you start moving patterns to inside other patterns, you risk to
lose the legibility:
A( b == B( ... ), c == C(...) )
Main problem I see is with cross product abuses:
A( oneb == B(...), thesameb == B(...) )
The above may match the same B as intended, but may also match other
Bs, leading to errors and bugs that will be hard to track.
I would continue making patterns explicit and not nested.
Although, the object navigability is desired and much waited I think:
$b : B(...)
A( c == $b.c )
Also, there are some cases that we would do good allowing nesting:
$c : Cheesery( ... )
$s : List( size < 3 ) from collect( Cheese( type == "stilton" ) from
$c.getCheeses() )
Just my .02 c.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
Don't have any antlr experience, but I'd say that would be a
very valuable
addition - probably more BAs would be able to pick it up this way (without
having to fallback on custom DSL)
Vlad
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: 20 March 2007 15:54
To: Rules Dev List
Subject: Re: [rules-dev] sugar
Could also allow:
Cheese( name = Person( location == "london").favourCheese )
Can also use this to constrain on the fact itself, instead of just a field:
Person( cheese = Cheese( type == "stilton ) )
This could be use in config options:
Call( duration < CallConf().minDuration )
But as Edson pointed out it is open to abuse and misunderstanding, how
long till people do:
Call( duration < CallConf().maxDuration, duration > CallConf().maxDuration )
Which is more like doing the following which has cross product issues:
CallConf( $maxDuration1 : maxDuration )
CallConf( $maxDuration2 : maxDuration )
Call( duration < ,$maxDuration1 duration > $maxDuration2 )
Mark
Mark Proctor wrote:
>I've been thinking of an idea to make rules more expressive, its just
>syntax sugar at the parser level, but thought i'd ask feedback - if
>anyone with antlr skills wants to make this work, let us know :)
>
>Instead of doing:
>$p : Person($favouriteCheese : favouriteCheese )
>Cheese( name == $favouriteCheese )
>
>We should allow the following:
>$p : Person()
>Cheese( name == $p.favouriteCheese )
>
>We could take this further and in places where a pattern is not used
>elsewhere allow:
>Cheese( name == Person().favouriteCheese )
>
>Mark
>
>
>
>_______________________________________________
>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
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
5:52 p.m.
New subject: sugar
I am not sure about the "danger", but I do like anything that avoids extra
binding.
So lets not throw the baby out with the bathwater.
I really like:
$p : Person()
Cheese( name == $p.favouriteCheese )
I think that should definately be allowed.
On 3/21/07, Edson Tirelli <tirelli(a)post.com> wrote:
I think it is a dangerous move.
It is easy for users to understand that each pattern matches a fact:
A( ... )
B( ... )
C( ... )
If you start moving patterns to inside other patterns, you risk to
lose the legibility:
A( b == B( ... ), c == C(...) )
Main problem I see is with cross product abuses:
A( oneb == B(...), thesameb == B(...) )
The above may match the same B as intended, but may also match other
Bs, leading to errors and bugs that will be hard to track.
I would continue making patterns explicit and not nested.
Although, the object navigability is desired and much waited I think:
$b : B(...)
A( c == $b.c )
Also, there are some cases that we would do good allowing nesting:
$c : Cheesery( ... )
$s : List( size < 3 ) from collect( Cheese( type == "stilton" ) from
$c.getCheeses() )
Just my .02 c.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
>Don't have any antlr experience, but I'd say that would be a very
valuable
>addition - probably more BAs would be able to pick it up this way
(without
>having to fallback on custom DSL)
>
>Vlad
>
>-----Original Message-----
>From: rules-dev-bounces(a)lists.jboss.org
>[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Mark Proctor
>Sent: 20 March 2007 15:54
>To: Rules Dev List
>Subject: Re: [rules-dev] sugar
>
>Could also allow:
>Cheese( name = Person( location == "london").favourCheese )
>
>Can also use this to constrain on the fact itself, instead of just a
field:
>Person( cheese = Cheese( type == "stilton ) )
>
>This could be use in config options:
>Call( duration < CallConf().minDuration )
>
>But as Edson pointed out it is open to abuse and misunderstanding, how
>long till people do:
>Call( duration < CallConf().maxDuration, duration >
CallConf().maxDuration )
>
>Which is more like doing the following which has cross product issues:
>CallConf( $maxDuration1 : maxDuration )
>CallConf( $maxDuration2 : maxDuration )
>Call( duration < ,$maxDuration1 duration > $maxDuration2 )
>
>Mark
>Mark Proctor wrote:
>
>
>>I've been thinking of an idea to make rules more expressive, its just
>>syntax sugar at the parser level, but thought i'd ask feedback - if
>>anyone with antlr skills wants to make this work, let us know :)
>>
>>Instead of doing:
>>$p : Person($favouriteCheese : favouriteCheese )
>>Cheese( name == $favouriteCheese )
>>
>>We should allow the following:
>>$p : Person()
>>Cheese( name == $p.favouriteCheese )
>>
>>We could take this further and in places where a pattern is not used
>>elsewhere allow:
>>Cheese( name == Person().favouriteCheese )
>>
>>Mark
>>
>>
>>
>>_______________________________________________
>>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
>_______________________________________________
>rules-dev mailing list
>rules-dev(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:22 p.m.
New subject: sugar
Yes, that is the part that I agreed.... :)
I just would NOT want:
Cheese( name == Person().favouriteCheese )
[]s
Edson
Michael Neale wrote:
I am not sure about the "danger", but I do like anything
that avoids
extra binding.
So lets not throw the baby out with the bathwater.
I really like:
$p : Person()
Cheese( name == $p.favouriteCheese )
I think that should definately be allowed.
On 3/21/07, *Edson Tirelli* <tirelli(a)post.com
<mailto:tirelli@post.com>> wrote:
I think it is a dangerous move.
It is easy for users to understand that each pattern matches a
fact:
A( ... )
B( ... )
C( ... )
If you start moving patterns to inside other patterns, you risk to
lose the legibility:
A( b == B( ... ), c == C(...) )
Main problem I see is with cross product abuses:
A( oneb == B(...), thesameb == B(...) )
The above may match the same B as intended, but may also match
other
Bs, leading to errors and bugs that will be hard to track.
I would continue making patterns explicit and not nested.
Although, the object navigability is desired and much waited I
think:
$b : B(...)
A( c == $b.c )
Also, there are some cases that we would do good allowing nesting:
$c : Cheesery( ... )
$s : List( size < 3 ) from collect( Cheese( type == "stilton" ) from
$c.getCheeses() )
Just my .02 c.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
>Don't have any antlr experience, but I'd say that would be a very
valuable
>addition - probably more BAs would be able to pick it up this way
(without
>having to fallback on custom DSL)
>
>Vlad
>
>-----Original Message-----
>From: rules-dev-bounces(a)lists.jboss.org
<mailto:rules-dev-bounces@lists.jboss.org>
>[mailto:rules-dev-bounces@lists.jboss.org
<mailto:rules-dev-bounces@lists.jboss.org>] On Behalf Of Mark Proctor
>Sent: 20 March 2007 15:54
>To: Rules Dev List
>Subject: Re: [rules-dev] sugar
>
>Could also allow:
>Cheese( name = Person( location == "london").favourCheese )
>
>Can also use this to constrain on the fact itself, instead of
just a field:
>Person( cheese = Cheese( type == "stilton ) )
>
>This could be use in config options:
>Call( duration < CallConf().minDuration )
>
>But as Edson pointed out it is open to abuse and
misunderstanding, how
>long till people do:
>Call( duration < CallConf().maxDuration, duration >
CallConf().maxDuration )
>
>Which is more like doing the following which has cross product
issues:
>CallConf( $maxDuration1 : maxDuration )
>CallConf( $maxDuration2 : maxDuration )
>Call( duration < ,$maxDuration1 duration > $maxDuration2 )
>
>Mark
>Mark Proctor wrote:
>
>
>>I've been thinking of an idea to make rules more expressive, its
just
>>syntax sugar at the parser level, but thought i'd ask feedback - if
>>anyone with antlr skills wants to make this work, let us know :)
>>
>>Instead of doing:
>>$p : Person($favouriteCheese : favouriteCheese )
>>Cheese( name == $favouriteCheese )
>>
>>We should allow the following:
>>$p : Person()
>>Cheese( name == $p.favouriteCheese )
>>
>>We could take this further and in places where a pattern is not
used
>>elsewhere allow:
>>Cheese( name == Person().favouriteCheese )
>>
>>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
>>
>>
>>
>
>_______________________________________________
>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
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com>
_______________________________________________
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
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
7:28 p.m.
New subject: sugar
Also, when I worked on protyping an analysis module a long time ago, it is
actually pretty easy to validate and "warn" people about possible
combination explosions (of course like all warnings, people are free to
ignore them) - but at least this means people are aware of the dangers.
On 3/21/07, Edson Tirelli <tirelli(a)post.com> wrote:
Yes, that is the part that I agreed.... :)
I just would NOT want:
Cheese( name == Person().favouriteCheese )
[]s
Edson
Michael Neale wrote:
> I am not sure about the "danger", but I do like anything that avoids
> extra binding.
> So lets not throw the baby out with the bathwater.
>
> I really like:
> $p : Person()
> Cheese( name == $p.favouriteCheese )
>
> I think that should definately be allowed.
>
>
> On 3/21/07, *Edson Tirelli* <tirelli(a)post.com
> <mailto:tirelli@post.com>> wrote:
>
>
> I think it is a dangerous move.
> It is easy for users to understand that each pattern matches a
> fact:
>
> A( ... )
> B( ... )
> C( ... )
>
> If you start moving patterns to inside other patterns, you risk
to
> lose the legibility:
>
> A( b == B( ... ), c == C(...) )
>
> Main problem I see is with cross product abuses:
>
> A( oneb == B(...), thesameb == B(...) )
>
> The above may match the same B as intended, but may also match
> other
> Bs, leading to errors and bugs that will be hard to track.
> I would continue making patterns explicit and not nested.
>
> Although, the object navigability is desired and much waited I
> think:
>
> $b : B(...)
> A( c == $b.c )
>
> Also, there are some cases that we would do good allowing
nesting:
>
> $c : Cheesery( ... )
> $s : List( size < 3 ) from collect( Cheese( type == "stilton" )
from
> $c.getCheeses() )
>
> Just my .02 c.
>
> []s
> Edson
>
> Olenin, Vladimir (MOH) wrote:
>
> >Don't have any antlr experience, but I'd say that would be a very
> valuable
> >addition - probably more BAs would be able to pick it up this way
> (without
> >having to fallback on custom DSL)
> >
> >Vlad
> >
> >-----Original Message-----
> >From: rules-dev-bounces(a)lists.jboss.org
> <mailto:rules-dev-bounces@lists.jboss.org>
> >[mailto:rules-dev-bounces@lists.jboss.org
> <mailto:rules-dev-bounces@lists.jboss.org>] On Behalf Of Mark
Proctor
> >Sent: 20 March 2007 15:54
> >To: Rules Dev List
> >Subject: Re: [rules-dev] sugar
> >
> >Could also allow:
> >Cheese( name = Person( location == "london").favourCheese )
> >
> >Can also use this to constrain on the fact itself, instead of
> just a field:
> >Person( cheese = Cheese( type == "stilton ) )
> >
> >This could be use in config options:
> >Call( duration < CallConf().minDuration )
> >
> >But as Edson pointed out it is open to abuse and
> misunderstanding, how
> >long till people do:
> >Call( duration < CallConf().maxDuration, duration >
> CallConf().maxDuration )
> >
> >Which is more like doing the following which has cross product
> issues:
> >CallConf( $maxDuration1 : maxDuration )
> >CallConf( $maxDuration2 : maxDuration )
> >Call( duration < ,$maxDuration1 duration > $maxDuration2 )
> >
> >Mark
> >Mark Proctor wrote:
> >
> >
> >>I've been thinking of an idea to make rules more expressive, its
> just
> >>syntax sugar at the parser level, but thought i'd ask feedback -
if
> >>anyone with antlr skills wants to make this work, let us know :)
> >>
> >>Instead of doing:
> >>$p : Person($favouriteCheese : favouriteCheese )
> >>Cheese( name == $favouriteCheese )
> >>
> >>We should allow the following:
> >>$p : Person()
> >>Cheese( name == $p.favouriteCheese )
> >>
> >>We could take this further and in places where a pattern is not
> used
> >>elsewhere allow:
> >>Cheese( name == Person().favouriteCheese )
> >>
> >>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
> >>
> >>
> >>
> >
> >_______________________________________________
> >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
> >
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3124-6000
> Mobile: +55 11 9218-4151
> JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com>
>
>
> _______________________________________________
> 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
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
4:39 a.m.
New subject: sugar
For what it's worth I like the thought of:-
$p : Person()
Cheese ( name == $p.favouriteCheese )
I like even more:-
$p : Person()
Cheese ( name == $p.favouriteFoods.favouriteCheese ) <-- i.e. object
model navigation
And possibly (subject to constrains such as "must be a Map" - I think
there's a similar requirement for extension of "contains"):-
$p : Person()
Cheese ( name == $p.favouriteFoods["cheese"] )
I'm with Edson (given my limited use) regarding pattern matches - it's
easier for me (as a user) to understand.
I can't say I understand what the cross-product issue is though (I know
"cross-product==bad").
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 20 March 2007 23:22
To: Rules Dev List
Subject: Re: [rules-dev] sugar
Yes, that is the part that I agreed.... :)
I just would NOT want:
Cheese( name == Person().favouriteCheese )
[]s
Edson
Michael Neale wrote:
I am not sure about the "danger", but I do like anything
that avoids
extra binding.
So lets not throw the baby out with the bathwater.
I really like:
$p : Person()
Cheese( name == $p.favouriteCheese )
I think that should definately be allowed.
On 3/21/07, *Edson Tirelli* <tirelli(a)post.com
<mailto:tirelli@post.com>> wrote:
I think it is a dangerous move.
It is easy for users to understand that each pattern matches a
fact:
A( ... )
B( ... )
C( ... )
If you start moving patterns to inside other patterns, you risk
to
lose the legibility:
A( b == B( ... ), c == C(...) )
Main problem I see is with cross product abuses:
A( oneb == B(...), thesameb == B(...) )
The above may match the same B as intended, but may also match
other
Bs, leading to errors and bugs that will be hard to track.
I would continue making patterns explicit and not nested.
Although, the object navigability is desired and much waited I
think:
$b : B(...)
A( c == $b.c )
Also, there are some cases that we would do good allowing
nesting:
$c : Cheesery( ... )
$s : List( size < 3 ) from collect( Cheese( type == "stilton" )
from
$c.getCheeses() )
Just my .02 c.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
>Don't have any antlr experience, but I'd say that would be a very
valuable
>addition - probably more BAs would be able to pick it up this way
(without
>having to fallback on custom DSL)
>
>Vlad
>
>-----Original Message-----
>From: rules-dev-bounces(a)lists.jboss.org
<mailto:rules-dev-bounces@lists.jboss.org>
>[mailto:rules-dev-bounces@lists.jboss.org
<mailto:rules-dev-bounces@lists.jboss.org>] On Behalf Of Mark
Proctor
>Sent: 20 March 2007 15:54
>To: Rules Dev List
>Subject: Re: [rules-dev] sugar
>
>Could also allow:
>Cheese( name = Person( location == "london").favourCheese )
>
>Can also use this to constrain on the fact itself, instead of
just a field:
>Person( cheese = Cheese( type == "stilton ) )
>
>This could be use in config options:
>Call( duration < CallConf().minDuration )
>
>But as Edson pointed out it is open to abuse and
misunderstanding, how
>long till people do:
>Call( duration < CallConf().maxDuration, duration >
CallConf().maxDuration )
>
>Which is more like doing the following which has cross product
issues:
>CallConf( $maxDuration1 : maxDuration )
>CallConf( $maxDuration2 : maxDuration )
>Call( duration < ,$maxDuration1 duration > $maxDuration2 )
>
>Mark
>Mark Proctor wrote:
>
>
>>I've been thinking of an idea to make rules more expressive, its
just
>>syntax sugar at the parser level, but thought i'd ask feedback -
if
>>anyone with antlr skills wants to make this work, let us
know :)
>>
>>Instead of doing:
>>$p : Person($favouriteCheese : favouriteCheese )
>>Cheese( name == $favouriteCheese )
>>
>>We should allow the following:
>>$p : Person()
>>Cheese( name == $p.favouriteCheese )
>>
>>We could take this further and in places where a pattern is not
used
>>elsewhere allow:
>>Cheese( name == Person().favouriteCheese )
>>
>>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
>>
>>
>>
>
>_______________________________________________
>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
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
<http://www.jboss.com>
_______________________________________________
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
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:59 a.m.
New subject: sugar
Cheese ( name == $p.favouriteFoods.favouriteCheese )
That is a different thing, because a rule engine can only understand the asserted facts
and their direct properties, so where as one is a short cut for a standard variable
constraint, the other in the expression above, would have to be swapped out for a return
value constraint with the expression executed by MVEL. That is also planned. However be
aware that excessive use of deep nested graphs will really just turn drools into a
standard scripting engine.
Mark
Anstis, Michael (M.) wrote:
For what it's worth I like the thought of:-
$p : Person()
Cheese ( name == $p.favouriteCheese )
I like even more:-
$p : Person()
Cheese ( name == $p.favouriteFoods.favouriteCheese ) <-- i.e. object
model navigation
And possibly (subject to constrains such as "must be a Map" - I think
there's a similar requirement for extension of "contains"):-
$p : Person()
Cheese ( name == $p.favouriteFoods["cheese"] )
I'm with Edson (given my limited use) regarding pattern matches - it's
easier for me (as a user) to understand.
I can't say I understand what the cross-product issue is though (I know
"cross-product==bad").
Cheers,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
Sent: 20 March 2007 23:22
To: Rules Dev List
Subject: Re: [rules-dev] sugar
Yes, that is the part that I agreed.... :)
I just would NOT want:
Cheese( name == Person().favouriteCheese )
[]s
Edson
Michael Neale wrote:
> I am not sure about the "danger", but I do like anything that avoids
> extra binding.
> So lets not throw the baby out with the bathwater.
>
> I really like:
> $p : Person()
> Cheese( name == $p.favouriteCheese )
>
> I think that should definately be allowed.
>
>
> On 3/21/07, *Edson Tirelli* <tirelli(a)post.com
> <mailto:tirelli@post.com>> wrote:
>
>
> I think it is a dangerous move.
> It is easy for users to understand that each pattern matches a
> fact:
>
> A( ... )
> B( ... )
> C( ... )
>
> If you start moving patterns to inside other patterns, you risk
>
to
> lose the legibility:
>
> A( b == B( ... ), c == C(...) )
>
> Main problem I see is with cross product abuses:
>
> A( oneb == B(...), thesameb == B(...) )
>
> The above may match the same B as intended, but may also match
> other
> Bs, leading to errors and bugs that will be hard to track.
> I would continue making patterns explicit and not nested.
>
> Although, the object navigability is desired and much waited I
> think:
>
> $b : B(...)
> A( c == $b.c )
>
> Also, there are some cases that we would do good allowing
>
nesting:
> $c : Cheesery( ... )
> $s : List( size < 3 ) from collect( Cheese( type == "stilton" )
>
from
> $c.getCheeses() )
>
> Just my .02 c.
>
> []s
> Edson
>
> Olenin, Vladimir (MOH) wrote:
>
> >Don't have any antlr experience, but I'd say that would be a very
> valuable
> >addition - probably more BAs would be able to pick it up this way
> (without
> >having to fallback on custom DSL)
> >
> >Vlad
> >
> >-----Original Message-----
> >From: rules-dev-bounces(a)lists.jboss.org
> <mailto:rules-dev-bounces@lists.jboss.org>
> >[mailto:rules-dev-bounces@lists.jboss.org
> <mailto:rules-dev-bounces@lists.jboss.org>] On Behalf Of Mark
>
Proctor
> >Sent: 20 March 2007 15:54
> >To: Rules Dev List
> >Subject: Re: [rules-dev] sugar
> >
> >Could also allow:
> >Cheese( name = Person( location == "london").favourCheese )
> >
> >Can also use this to constrain on the fact itself, instead of
> just a field:
> >Person( cheese = Cheese( type == "stilton ) )
> >
> >This could be use in config options:
> >Call( duration < CallConf().minDuration )
> >
> >But as Edson pointed out it is open to abuse and
> misunderstanding, how
> >long till people do:
> >Call( duration < CallConf().maxDuration, duration >
> CallConf().maxDuration )
> >
> >Which is more like doing the following which has cross product
> issues:
> >CallConf( $maxDuration1 : maxDuration )
> >CallConf( $maxDuration2 : maxDuration )
> >Call( duration < ,$maxDuration1 duration > $maxDuration2 )
> >
> >Mark
> >Mark Proctor wrote:
> >
> >
> >>I've been thinking of an idea to make rules more expressive, its
> just
> >>syntax sugar at the parser level, but thought i'd ask feedback -
>
if
> >>anyone with antlr skills wants to make this work, let us know :)
> >>
> >>Instead of doing:
> >>$p : Person($favouriteCheese : favouriteCheese )
> >>Cheese( name == $favouriteCheese )
> >>
> >>We should allow the following:
> >>$p : Person()
> >>Cheese( name == $p.favouriteCheese )
> >>
> >>We could take this further and in places where a pattern is not
> used
> >>elsewhere allow:
> >>Cheese( name == Person().favouriteCheese )
> >>
> >>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
> >>
> >>
> >>
> >
> >_______________________________________________
> >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
> >
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3124-6000
> Mobile: +55 11 9218-4151
> JBoss, a division of Red Hat @ www.jboss.com
>
<http://www.jboss.com>
> _______________________________________________
> 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
>
>
>
6298
days inactive
6299
days old
6 comments
5 participants
participants (5)
-
Anstis, Michael (M.) -
Edson Tirelli -
Mark Proctor -
Michael Neale -
Olenin, Vladimir (MOH)