[rules-dev] Drools syntax diagrams - redrawn
Mark Proctor
mproctor at codehaus.org
Wed Sep 22 11:52:49 EDT 2010
On 22/09/2010 16:27, Anstis, Michael (M.) wrote:
> Why the two different operators for in- and cross-pattern "or"
> i.e. "||" and "or". What a pain that surely would be from a user
> perspective...
At the moment you can use both 'or' and '||' infix between patterns,
probably becuse we couldn't decide what was best so added both. Inside
of patterns only '||' made sense. I think 'or' was added between
patterns to keep similarity to allow levels of comfort for Clips and
Jess users. In a way as other Conditional Elements are keywords removing
'||' between patterns and only using 'or' might be easier, it also helps
visually differentiate bewteen or inside of a pattern and outside. But
I'm also open to just using '||' everywhere for consistency, this is
something we need to decide and agree between us.
> Where does that fit in with the language orthogonality too (blogged
> about by Edson some time ago - sorry to drag the past up
> http://tirelli.blogspot.com/2007/08/quick-catch-up-and-language.html)?
Simplying the language, removing redundanceis and special cases all
helps for that. Edsons work on generic expressions inside of patterns
helps remove a lot of cruft.
Mark
> +1 for infix too :-)
I think it will be infix, that's what most people seem to prefer.
Mark
>
> ------------------------------------------------------------------------
> *From:* rules-dev-bounces at lists.jboss.org
> [mailto:rules-dev-bounces at lists.jboss.org] *On Behalf Of *Mark Proctor
> *Sent:* 22 September 2010 16:03
> *To:* rules-dev at lists.jboss.org
> *Subject:* Re: [rules-dev] Drools syntax diagrams - redrawn
>
> 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
>>
>> 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
>
>
> _______________________________________________
> 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/8e1faf54/attachment.html
More information about the rules-dev
mailing list