[rules-dev] sugar

[Michael Neale]

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> 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] 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
> >>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
> >_______________________________________________
> >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/f5ddbebb/attachment.html