Re: [rules-dev] 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 &gt;&gt;rules-dev(a)lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> > >_______________________________________________ >rules-dev mailing list &gt;rules-dev(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/rules-dev >_______________________________________________ >rules-dev mailing list &gt;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