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@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@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@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@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/rules-dev
>     >>
>     >>
>     >>
>     >
>     >_______________________________________________
>     >rules-dev mailing list
>     >rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/rules-dev
>     >_______________________________________________
>     >rules-dev mailing list
>     >rules-dev@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@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rules-dev mailing list
>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


_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev