On 22/09/2010 17:20, Wolfgang Laun wrote:
See my remarks inline.
On 22 September 2010 17:03, Mark Proctor <[email protected]
<mailto:[email protected]>> wrote:
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.
OK, a clear distinction avoids confusion.
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( ...) )
(name ... ) is neither function style nor infix, so removing yet
another way of writing expressions is OK. Let's infix.
The prefix way, shown above was following what jess and clips did. Our
initial mindset was based on those two engines, in trying to make a more
comfortable environment for them to transition too. We are now in a more
comfortable position and able to do what is right for our existing
community and worry less about appealing to other communities.
Mark
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.
OK!
Davide has also requested that we make $ prefix mandatory for LHS
bindings as that is deterministic and again makes the grammar cleaner.
I don't understand why it should be "cleaner". After all, a '$' could
even result from a Java identifier although this is discouraged,
according to the Language Spec.
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.
There's one thing that would help: Make the NT identifiers in the
grammar "user friendly". I had to replace all of them with NT
identifiers that are self-explanatory. Also, whenever possible, stick
to the terms in the Java grammar if it's the same thing, e.g.
"QualifiedIdentifier", "Block", "Expression", etc.
-W
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] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
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
