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.) <[email protected]
<mailto:[email protected]>> wrote:
What was the service and was it the ANTLR grammar you uploaded to
generate the images?
Thanks,
Mike
-----Original Message-----
From: [email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] 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
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
