[rules-dev] sugar
Mark Proctor
mproctor at codehaus.org
Wed Mar 21 10:59:43 EDT 2007
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 at lists.jboss.org
> [mailto:rules-dev-bounces at 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 at post.com
>> <mailto:tirelli at 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 at lists.jboss.org
>> <mailto:rules-dev-bounces at lists.jboss.org>
>> >[mailto:rules-dev-bounces at lists.jboss.org
>> <mailto:rules-dev-bounces at 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> >>https://lists.jboss.org/mailman/listinfo/rules-dev
>> >>
>> >>
>> >>
>> >
>> >_______________________________________________
>> >rules-dev mailing list
>> >rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/rules-dev
>> >_______________________________________________
>> >rules-dev mailing list
>> >rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> >https://lists.jboss.org/mailman/listinfo/rules-dev
>> >
>> >
>> >
>>
>>
>> --
>> Edson Tirelli
>> 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> -----------------------------------------------------------------------
>>
> -
>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070321/62f32b0b/attachment.html
More information about the rules-dev
mailing list