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.
<br><br><div><span class="gmail_quote">On 3/21/07, <b class="gmail_sendername">Edson Tirelli</b> <<a href="mailto:tirelli@post.com">tirelli@post.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> Yes, that is the part that I agreed.... :)<br> I just would NOT want:<br><br>Cheese( name == Person().favouriteCheese )<br><br> []s<br> Edson<br><br>Michael Neale wrote:<br><br>> I am not sure about the "danger", but I do like anything that avoids
<br>> extra binding.<br>> So lets not throw the baby out with the bathwater.<br>><br>> I really like:<br>> $p : Person()<br>> Cheese( name == $p.favouriteCheese )<br>><br>> I think that should definately be allowed.
<br>><br>><br>> On 3/21/07, *Edson Tirelli* <<a href="mailto:tirelli@post.com">tirelli@post.com</a><br>> <mailto:<a href="mailto:tirelli@post.com">tirelli@post.com</a>>> wrote:<br>><br>><br>> I think it is a dangerous move.
<br>> It is easy for users to understand that each pattern matches a<br>> fact:<br>><br>> A( ... )<br>> B( ... )<br>> C( ... )<br>><br>> If you start moving patterns to inside other patterns, you risk to
<br>> lose the legibility:<br>><br>> A( b == B( ... ), c == C(...) )<br>><br>> Main problem I see is with cross product abuses:<br>><br>> A( oneb == B(...), thesameb == B(...) )<br>
><br>> The above may match the same B as intended, but may also match<br>> other<br>> Bs, leading to errors and bugs that will be hard to track.<br>> I would continue making patterns explicit and not nested.
<br>><br>> Although, the object navigability is desired and much waited I<br>> think:<br>><br>> $b : B(...)<br>> A( c == $b.c )<br>><br>> Also, there are some cases that we would do good allowing nesting:
<br>><br>> $c : Cheesery( ... )<br>> $s : List( size < 3 ) from collect( Cheese( type == "stilton" ) from<br>> $c.getCheeses() )<br>><br>> Just my .02 c.<br>><br>> []s
<br>> Edson<br>><br>> Olenin, Vladimir (MOH) wrote:<br>><br>> >Don't have any antlr experience, but I'd say that would be a very<br>> valuable<br>> >addition - probably more BAs would be able to pick it up this way
<br>> (without<br>> >having to fallback on custom DSL)<br>> ><br>> >Vlad<br>> ><br>> >-----Original Message-----<br>> >From: <a href="mailto:rules-dev-bounces@lists.jboss.org">
rules-dev-bounces@lists.jboss.org</a><br>> <mailto:<a href="mailto:rules-dev-bounces@lists.jboss.org">rules-dev-bounces@lists.jboss.org</a>><br>> >[mailto:<a href="mailto:rules-dev-bounces@lists.jboss.org">
rules-dev-bounces@lists.jboss.org</a><br>> <mailto:<a href="mailto:rules-dev-bounces@lists.jboss.org">rules-dev-bounces@lists.jboss.org</a>>] On Behalf Of Mark Proctor<br>> >Sent: 20 March 2007 15:54
<br>> >To: Rules Dev List<br>> >Subject: Re: [rules-dev] sugar<br>> ><br>> >Could also allow:<br>> >Cheese( name = Person( location == "london").favourCheese )<br>
> ><br>> >Can also use this to constrain on the fact itself, instead of<br>> just a field:<br>> >Person( cheese = Cheese( type == "stilton ) )<br>> ><br>> >This could be use in config options:
<br>> >Call( duration < CallConf().minDuration )<br>> ><br>> >But as Edson pointed out it is open to abuse and<br>> misunderstanding, how<br>> >long till people do:<br>> >Call( duration < CallConf().maxDuration, duration >
<br>> CallConf().maxDuration )<br>> ><br>> >Which is more like doing the following which has cross product<br>> issues:<br>> >CallConf( $maxDuration1 : maxDuration )<br>> >CallConf( $maxDuration2 : maxDuration )
<br>> >Call( duration < ,$maxDuration1 duration > $maxDuration2 )<br>> ><br>> >Mark<br>> >Mark Proctor wrote:<br>> ><br>> ><br>> >>I've been thinking of an idea to make rules more expressive, its
<br>> just<br>> >>syntax sugar at the parser level, but thought i'd ask feedback - if<br>> >>anyone with antlr skills wants to make this work, let us know :)<br>> >><br>> >>Instead of doing:
<br>> >>$p : Person($favouriteCheese : favouriteCheese )<br>> >>Cheese( name == $favouriteCheese )<br>> >><br>> >>We should allow the following:<br>> >>$p : Person()
<br>> >>Cheese( name == $p.favouriteCheese )<br>> >><br>> >>We could take this further and in places where a pattern is not<br>> used<br>> >>elsewhere allow:<br>> >>Cheese( name == Person().favouriteCheese )
<br>> >><br>> >>Mark<br>> >><br>> >><br>> >><br>> >>_______________________________________________<br>> >>rules-dev mailing list<br>
> >><a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a> <mailto:<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>><br>> >><a href="https://lists.jboss.org/mailman/listinfo/rules-dev">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>> >><br>> >><br>> >><br>> ><br>> >_______________________________________________<br>> >rules-dev mailing list
<br>> ><a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a> <mailto:<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>><br>> > <a href="https://lists.jboss.org/mailman/listinfo/rules-dev">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>> >_______________________________________________<br>> >rules-dev mailing list<br>> ><a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org
</a> <mailto:<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>><br>> ><a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
<br>> ><br>> ><br>> ><br>><br>><br>> --<br>> Edson Tirelli<br>> Software Engineer - JBoss Rules Core Developer<br>> Office: +55 11 3124-6000<br>> Mobile: +55 11 9218-4151
<br>> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a> <<a href="http://www.jboss.com">http://www.jboss.com</a>><br>><br>><br>> _______________________________________________
<br>> rules-dev mailing list<br>> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a> <mailto:<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>><br>>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>><br>><br>>------------------------------------------------------------------------<br>><br>
>_______________________________________________<br>>rules-dev mailing list<br>><a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>><a href="https://lists.jboss.org/mailman/listinfo/rules-dev">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>><br>><br><br><br>--<br> Edson Tirelli<br> Software Engineer - JBoss Rules Core Developer<br> Office: +55 11 3124-6000<br> Mobile: +55 11 9218-4151<br> JBoss, a division of Red Hat @
<a href="http://www.jboss.com">www.jboss.com</a><br><br><br>_______________________________________________<br>rules-dev mailing list<br><a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-dev">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br></blockquote></div><br>