[rules-dev] Drools syntax diagrams - redrawn

Mark Proctor mproctor at codehaus.org
Wed Sep 22 11:05:29 EDT 2010


  On 22/09/2010 16:03, Mark Proctor wrote:
> On 22/09/2010 14:40, Wolfgang Laun wrote:
>> Service:
>> http://www-cgi.uni-regensburg.de/~brf09510/syntax.html 
>> <http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.html>
>>
>> The grammar syntax is the same as used in DRL.g but stripped of all 
>> the antsy additions, and simplified.
>>
>> @Mark: I'm well aware of the limitations of a 1:1 translation of a 
>> parser's grammar into diagrams. I have reduced the splits into 
>> separate rules in DRL.g considerably. But what do you want to hide 
>> from the users? The syntax is the syntax, and there's no 
>> sweet-talking around it after you have reduced all the noise from 
>> technical splits.
>>
>> One thing that might help would be deprecating things like infix or/and.
> yes agreed. Simplifying the grammar, reducing ambigiiouty or multiple 
> ways of doing the same thing, will make any resulting grammar both 
> easier ot maintain and grok.
>
> Edson, Davide and I have already discuss this. Both are working on a 
> new parser and are trying to address these issues. So things that are 
> doing are:
>
> Single binding on 'or'
> $binding : ( Pattern() || Pattern() )
>
> We are thinking of only allowing 'or' between patterns and not 
> allowing users to mix and match 'or' and '||'.  Inside of patterns 
> '||' is the only connective allowed and will remain so.
>
> We will also probably make a choice and only allow infix 'or' and 
> 'and', at the moment users can chose infix or prefix. Personally I 
> find prefix quite attractive as it works sort of like a "choice":
> (or Person(  ... )
>       Person( ... )
>       Person( ...) )
>
> But I think most peopel are more comfortable with infix:
> (Person(  ... ) or
>   Person( ... ) or
>   Person( ...) )
>
> return value, eval, literal constraint, variable constraint are going. 
> These are left overs of a Clips based grammar. So instead we'll have a 
> generic "expr" class that follow more common modern ASTs for 
> expression engines, like say MVEL.
>
> Davide has also requested that we make $ prefix mandatory for LHS 
> bindings as that is deterministic and again makes the grammar cleaner. 
> I personally like it being optional and it's still open to debate. But 
> I recognise the need to have better maintained grammar, that is more 
> consistent and regular with easy to main documentation.
>
> Mark
I would add that these would be backward compatability breaking changes, 
we've been backwards compatible now for almost 5 years....  However it 
shouldn't be too hard to have a 5.x parser spit out 6.x compatible DRL.

Mark
>>
>> Some rules can be omitted if they coincide with Java's own rules; 
>> just add an explanation.
>>
>> -W
>>
>>
>> On 22 September 2010 14:56, Anstis, Michael (M.) <manstis1 at ford.com 
>> <mailto:manstis1 at ford.com>> wrote:
>>
>>     What was the service and was it the ANTLR grammar you uploaded to
>>     generate the images?
>>
>>     Thanks,
>>
>>     Mike
>>
>>     -----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 Wolfgang
>>     Laun
>>     Sent: 22 September 2010 13:38
>>     To: Rules Dev List
>>     Subject: [rules-dev] Drools syntax diagrams - redrawn
>>
>>     I've found this online service and stuffed the Drools grammar
>>     into it.
>>
>>     You may see the results while they are still there:
>>     http://www-cgi.uni-regensburg.de/~brf09510/syntax.tmp/x45371x0x0x.ebnf.h
>>     tml
>>     <http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebnf.h%0Atml>
>>     <http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn
>>     f.html
>>     <http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn%0Af.html>>
>>
>>     -W
>>
>>
>>
>>     _______________________________________________
>>     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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20100922/287e6226/attachment.html 


More information about the rules-dev mailing list