7:37 a.m.
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.ht...
-W
7:56 a.m.
What was the service and was it the ANTLR grammar you uploaded to
generate the images?
Thanks,
Mike
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@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.ebn
f.html>
-W
8:40 a.m.
Service:
http://www-cgi.uni-regensburg.de/~brf09510/syntax.html<http://www-cgi....
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.
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(a)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(a)lists.jboss.org
[mailto:rules-dev-bounces@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:40 a.m.
I agree with Wolfgang here in the sense that it is much better a
low level, not so friendly, ****up-to-date**** diagram, than the
higher level, manually drawn diagrams that we end up never having the
time to update...
Just my 0.02c.
PS: but I would prefer deprecating pre-fixed or/and instead of
infix... hehehehe
Edson
2010/9/22 Wolfgang Laun <wolfgang.laun(a)gmail.com>:
Service:
http://www-cgi.uni-regensburg.de/~brf09510/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.
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(a)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(a)lists.jboss.org
> [mailto:rules-dev-bounces@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.ebn
> f.html>
>
> -W
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
10:03 a.m.
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(a)ford.com
<mailto:manstis1@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(a)lists.jboss.org
<mailto:rules-dev-bounces@lists.jboss.org>
[mailto:rules-dev-bounces@lists.jboss.org
<mailto:rules-dev-bounces@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....
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn
f.html
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn%0...
-W
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
10:05 a.m.
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(a)ford.com
> <mailto:manstis1@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(a)lists.jboss.org
> <mailto:rules-dev-bounces@lists.jboss.org>
> [mailto:rules-dev-bounces@lists.jboss.org
> <mailto:rules-dev-bounces@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....
> <http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn
> f.html
>
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn%0...
>
> -W
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
10:27 a.m.
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...
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)?
+1 for infix too :-)
________________________________
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: 22 September 2010 16:03
To: rules-dev(a)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(a)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(a)lists.jboss.org
[mailto:rules-dev-bounces@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.ebn
f.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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
10:52 a.m.
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(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] *On Behalf Of *Mark Proctor
*Sent:* 22 September 2010 16:03
*To:* rules-dev(a)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(a)ford.com <mailto:manstis1@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(a)lists.jboss.org
> <mailto:rules-dev-bounces@lists.jboss.org>
> [mailto:rules-dev-bounces@lists.jboss.org
> <mailto:rules-dev-bounces@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....
> <http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn
> f.html
>
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn%0...
>
> -W
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:20 a.m.
See my remarks inline.
On 22 September 2010 17:03, Mark Proctor <mproctor(a)codehaus.org> 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.
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.) <manstis1(a)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(a)lists.jboss.org
> [mailto:rules-dev-bounces@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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:45 a.m.
On 22/09/2010 17:20, Wolfgang Laun wrote:
See my remarks inline.
On 22 September 2010 17:03, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> 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.)
> <manstis1(a)ford.com <mailto:manstis1@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(a)lists.jboss.org
> <mailto:rules-dev-bounces@lists.jboss.org>
> [mailto:rules-dev-bounces@lists.jboss.org
> <mailto:rules-dev-bounces@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....
> <http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn
> f.html
>
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn%0...
>
> -W
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
2:31 a.m.
FWIW: in Perl, there are both operators as well (|| and 'or').
However, they are *not* exactly the same. Although they can be used in
any context to render a boolean expression, their priority makes the
difference. Taken from official documentation (http://bit.ly/dgw4GT):
Binary "or" returns the logical disjunction of the two
surrounding
expressions. It's equivalent to || except for the very low
precedence. This makes it useful for control flow.
Nonetheless, it must be taken into account that the distinction makes
sense for a Perl programmer. For a rules-writing guy (or girl) perhaps
the distinction is extremely obscure.
Regards.
On 22/09/2010, at 18:20, Wolfgang Laun wrote:
See my remarks inline.
On 22 September 2010 17:03, Mark Proctor <mproctor(a)codehaus.org>
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.
--
Bruno Unna
Public key available
3:03 a.m.
On 23 September 2010 09:31, Bruno Unna <bruno.unna(a)gmail.com> wrote:
FWIW: in Perl, there are both operators as well (|| and
'or'). However,
they are *not* exactly the same. Although they can be used in any context to
render a boolean expression, their priority makes the difference. Taken from
official documentation (http://bit.ly/dgw4GT):
Low precedence "and", "or", "xor" were introduced to
permit "Perl poetry",
or, more seriously, to
permit control flow using a logical expression, especially after function
calls without parentheses.
see Naples or die; # same as: see(Napes) || die(); but not: see(Naples
|| die() );
No way this makes any sense in Drools.
-W
Binary "or" returns the logical disjunction of the two surrounding
expressions. It's equivalent to || except for the very low
precedence. This
makes it useful for control flow.
Nonetheless, it must be taken into account that the distinction makes sense
for a Perl programmer. For a rules-writing guy (or girl) perhaps the
distinction is extremely obscure.
Regards.
8:02 a.m.
On 22/09/2010 13:37, Wolfgang Laun wrote:
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.html
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebnf....
I found one of the problems with generated rail road diagrams is that
they are often too low level, making it hard for them to be useful. They
often splits things up into too small a pieces, as they are a literal
translation of the grammar and not a logical representation for end
users. That said it, it's probably better to have well maintained
generated versinos, than out of date hand created ones. Just a shame
there isn't a tool that allows for easy hand editing of rail raod diagrams.
I think part of the problem is caused by the lack of consistency in our
grammar for exressions - evals, return values etc. Edson is working on
that so we have a generic and clean grammar for expressions, this should
add more regularity to our grammar.
Mark
-W
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5232
days inactive
5233
days old
12 comments
5 participants
participants (5)
-
Anstis, Michael (M.) -
Bruno Unna -
Edson Tirelli -
Mark Proctor -
Wolfgang Laun