[rules-dev] sugar

[Michael Neale]

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 at 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 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
> >
> >
>
>
> --
> 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 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/68814298/attachment.html