2:28 p.m.
All,
BACKGROUND:
As Drools moves forward, we need to be able to declare several new
structures, as well as make existing structures more robust for compile time
analysis, error reporting and tooling support. For instance, as it is today,
entry points are implicit declared by simply using them, i.e., if someone
writes a pattern:
X() from entry-point Y
The engine will create entry-point Y implicitly. This is easy to use, but
this makes it impossible for the engine to detect typos and report during
compilation time. So, the idea is that we will allow the user to declare all
the entry points he wants to use in his application and we will have a
configuration option to enforce or not that list of declared entry points.
If the configuration is set to enforce and the engine finds a rule that is
using an entry point that is not part of the list, the engine can raise a
compile time error point out the user's mistake. E.g., using pseudo code:
declare entry-point X, Y
declare entry-point Z
Drools also needs a way to declare named windows for re-use on multiple
rules. For instance, using pseudo code:
declare window X
@type( tumbling )
@keep( last 10 )
StockTick( symbol == "RHT" ) from entry-point Y
end
And in the rule:
rule Z
when
StockTick() from window:named X
then
...
end
QUESTION:
As we can see above, we will need several new constructs in order to
support features in our roadmap. We have the choice of making them all top
level constructs, making the error recovery in the parser a lot more
complicated, or we can re-use our declare construct to define these new
structures as I presented in the pseudo-code above. Any pros/cons you can
see in such approach?
OPTION 1 (more verbose, but simpler and more stable):
<epDeclaration> ::= declare entry-point <epName> [, <epName]*
<windowDeclaration> ::= declare window <windowName>
<restOfTheWindowDeclaration> end
<typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
end
OPTION 2 (makes error recovery harder, but it is less verbose):
<epDeclaration> ::= entry-point <epName> [, <epName]*
<windowDeclaration> ::= window <windowName> <restOfTheWindowDeclaration>
end
<typeDeclaration> ::= declare <typeName> <restOfTheTypeDeclaration> end
OPTION 3:
<epDeclaration> ::= someOtherKeyword entry-point <epName> [, <epName]*
<windowDeclaration> ::= someOtherKeyword window <windowName>
<restOfTheWindowDeclaration> end
<typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
end
Edson
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
3:28 p.m.
Personally, I don't see a problem with option 1.
For consistency (with entry-points) the named windows and usage thereof
should, IMO, be defined thus:-
*
*
**declare window X
@type( tumbling )
@keep( last 10 )
StockTick( symbol == "RHT" ) from entry-point Y
end
rule Z
when
StockTick() from window x
then
...
end
I assume the window declaration supersedes "over window:length" and "over
window:time", since the semantics seem to be defined in the declaration.
Please let me know when this is closer to reality as Guvnor will need to
support this.
Cheers,
Mike
On 26 July 2011 20:28, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
All,
BACKGROUND:
As Drools moves forward, we need to be able to declare several new
structures, as well as make existing structures more robust for compile time
analysis, error reporting and tooling support. For instance, as it is today,
entry points are implicit declared by simply using them, i.e., if someone
writes a pattern:
X() from entry-point Y
The engine will create entry-point Y implicitly. This is easy to use,
but this makes it impossible for the engine to detect typos and report
during compilation time. So, the idea is that we will allow the user to
declare all the entry points he wants to use in his application and we will
have a configuration option to enforce or not that list of declared entry
points. If the configuration is set to enforce and the engine finds a rule
that is using an entry point that is not part of the list, the engine can
raise a compile time error point out the user's mistake. E.g., using pseudo
code:
declare entry-point X, Y
declare entry-point Z
Drools also needs a way to declare named windows for re-use on multiple
rules. For instance, using pseudo code:
declare window X
@type( tumbling )
@keep( last 10 )
StockTick( symbol == "RHT" ) from entry-point Y
end
And in the rule:
rule Z
when
StockTick() from window:named X
then
...
end
QUESTION:
As we can see above, we will need several new constructs in order to
support features in our roadmap. We have the choice of making them all top
level constructs, making the error recovery in the parser a lot more
complicated, or we can re-use our declare construct to define these new
structures as I presented in the pseudo-code above. Any pros/cons you can
see in such approach?
OPTION 1 (more verbose, but simpler and more stable):
<epDeclaration> ::= declare entry-point <epName> [, <epName]*
<windowDeclaration> ::= declare window <windowName>
<restOfTheWindowDeclaration> end
<typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
end
OPTION 2 (makes error recovery harder, but it is less verbose):
<epDeclaration> ::= entry-point <epName> [, <epName]*
<windowDeclaration> ::= window <windowName>
<restOfTheWindowDeclaration>
end
<typeDeclaration> ::= declare <typeName> <restOfTheTypeDeclaration>
end
OPTION 3:
<epDeclaration> ::= someOtherKeyword entry-point <epName> [, <epName]*
<windowDeclaration> ::= someOtherKeyword window <windowName>
<restOfTheWindowDeclaration> end
<typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
end
Edson
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
3:36 p.m.
Thanks for the feedback Michael, and you are right, it will replace the
previous way of dealing with windows, but we will still support the old way
for backward compatibility.
The idea is to have this working in the engine for Beta1, so I will let
you know as soon as the parser is done in the next couple days for you to
implement in guvnor as your schedule allow it.
Thanks,
Edson
2011/7/26 Michael Anstis <michael.anstis(a)gmail.com>
Personally, I don't see a problem with option 1.
For consistency (with entry-points) the named windows and usage thereof
should, IMO, be defined thus:-
*
*
**declare window X
@type( tumbling )
@keep( last 10 )
StockTick( symbol == "RHT" ) from entry-point Y
end
rule Z
when
StockTick() from window x
then
...
end
I assume the window declaration supersedes "over window:length" and "over
window:time", since the semantics seem to be defined in the declaration.
Please let me know when this is closer to reality as Guvnor will need to
support this.
Cheers,
Mike
On 26 July 2011 20:28, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
>
> All,
>
> BACKGROUND:
> As Drools moves forward, we need to be able to declare several new
> structures, as well as make existing structures more robust for compile time
> analysis, error reporting and tooling support. For instance, as it is today,
> entry points are implicit declared by simply using them, i.e., if someone
> writes a pattern:
>
> X() from entry-point Y
>
> The engine will create entry-point Y implicitly. This is easy to use,
> but this makes it impossible for the engine to detect typos and report
> during compilation time. So, the idea is that we will allow the user to
> declare all the entry points he wants to use in his application and we will
> have a configuration option to enforce or not that list of declared entry
> points. If the configuration is set to enforce and the engine finds a rule
> that is using an entry point that is not part of the list, the engine can
> raise a compile time error point out the user's mistake. E.g., using pseudo
> code:
>
> declare entry-point X, Y
> declare entry-point Z
>
> Drools also needs a way to declare named windows for re-use on multiple
> rules. For instance, using pseudo code:
>
> declare window X
> @type( tumbling )
> @keep( last 10 )
> StockTick( symbol == "RHT" ) from entry-point Y
> end
>
> And in the rule:
>
> rule Z
> when
> StockTick() from window:named X
> then
> ...
> end
>
> QUESTION:
> As we can see above, we will need several new constructs in order to
> support features in our roadmap. We have the choice of making them all top
> level constructs, making the error recovery in the parser a lot more
> complicated, or we can re-use our declare construct to define these new
> structures as I presented in the pseudo-code above. Any pros/cons you can
> see in such approach?
>
> OPTION 1 (more verbose, but simpler and more stable):
> <epDeclaration> ::= declare entry-point <epName> [, <epName]*
> <windowDeclaration> ::= declare window <windowName>
> <restOfTheWindowDeclaration> end
> <typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
> end
>
> OPTION 2 (makes error recovery harder, but it is less verbose):
> <epDeclaration> ::= entry-point <epName> [, <epName]*
> <windowDeclaration> ::= window <windowName>
<restOfTheWindowDeclaration>
> end
> <typeDeclaration> ::= declare <typeName> <restOfTheTypeDeclaration>
end
>
> OPTION 3:
> <epDeclaration> ::= someOtherKeyword entry-point <epName> [,
<epName]*
> <windowDeclaration> ::= someOtherKeyword window <windowName>
> <restOfTheWindowDeclaration> end
> <typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
> end
>
>
> Edson
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> 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
12:34 a.m.
On 26 July 2011 21:28, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
QUESTION:
As we can see above, we will need several new constructs in order to
support features in our roadmap. We have the choice of making them all top
level constructs, making the error recovery in the parser a lot more
complicated, or we can re-use our declare construct to define these new
structures as I presented in the pseudo-code above. Any pros/cons you can
see in such approach?
I doubt the "a lot more complicated". I'd much rather have a
"natural
language" with a lean syntax than the cobol-ish agglomeration of keywords.
Structured/syntax assisted editing should take care of gross errors so that
recovery isn't as important as without these aids.
I vote for OPTION 2. I'm very much against OPTION 3.
Wolfgang
OPTION 1 (more verbose, but simpler and more stable):
<epDeclaration> ::= declare entry-point <epName> [, <epName]*
<windowDeclaration> ::= declare window <windowName>
<restOfTheWindowDeclaration> end
<typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
end
OPTION 2 (makes error recovery harder, but it is less verbose):
<epDeclaration> ::= entry-point <epName> [, <epName]*
<windowDeclaration> ::= window <windowName>
<restOfTheWindowDeclaration>
end
<typeDeclaration> ::= declare <typeName> <restOfTheTypeDeclaration>
end
OPTION 3:
<epDeclaration> ::= someOtherKeyword entry-point <epName> [, <epName]*
<windowDeclaration> ::= someOtherKeyword window <windowName>
<restOfTheWindowDeclaration> end
<typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
end
Edson
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8:34 a.m.
Just to explain how the parser recovers from errors, it tries to skip a
token that fail to match the construct being parsed. If that still fails, it
will skip all tokens until it finds the start of a top level construct (i.e.
a statement like a rule, query, declare, etc) and resynch from there. If you
have too many different top level keywords, it increases the probability
that there will be a keyword clash and it will fail to resynch, resulting in
cobolish errors for the rest of the file... :) those who ever forgot a . in
a cobol program using a compiler from the 70's-80's, that caused the
generation of 983045 compilation errors raise their hand! ;)
But yes, I see your point, and we might do that.
Just another example, most CEP products are still based in SQL-sh
languages, and they use the "create" keyword for everything. "create
window...", "create schema/table..." (schema/table meaning event types),
etc...
Edson
2011/7/27 Wolfgang Laun <wolfgang.laun(a)gmail.com>
On 26 July 2011 21:28, Edson Tirelli <ed.tirelli(a)gmail.com>
wrote:
> QUESTION:
> As we can see above, we will need several new constructs in order to
> support features in our roadmap. We have the choice of making them all top
> level constructs, making the error recovery in the parser a lot more
> complicated, or we can re-use our declare construct to define these new
> structures as I presented in the pseudo-code above. Any pros/cons you can
> see in such approach?
>
>
I doubt the "a lot more complicated". I'd much rather have a "natural
language" with a lean syntax than the cobol-ish agglomeration of keywords.
Structured/syntax assisted editing should take care of gross errors so that
recovery isn't as important as without these aids.
I vote for OPTION 2. I'm very much against OPTION 3.
Wolfgang
> OPTION 1 (more verbose, but simpler and more stable):
> <epDeclaration> ::= declare entry-point <epName> [, <epName]*
> <windowDeclaration> ::= declare window <windowName>
> <restOfTheWindowDeclaration> end
> <typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
> end
>
> OPTION 2 (makes error recovery harder, but it is less verbose):
> <epDeclaration> ::= entry-point <epName> [, <epName]*
> <windowDeclaration> ::= window <windowName>
<restOfTheWindowDeclaration>
> end
> <typeDeclaration> ::= declare <typeName> <restOfTheTypeDeclaration>
end
>
> OPTION 3:
> <epDeclaration> ::= someOtherKeyword entry-point <epName> [,
<epName]*
> <windowDeclaration> ::= someOtherKeyword window <windowName>
> <restOfTheWindowDeclaration> end
> <typeDeclaration> ::= declare [type] <typeName>
<restOfTheTypeDeclaration>
> end
>
>
> Edson
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> 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
8:44 a.m.
On 27 July 2011 15:34, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
Just to explain how the parser recovers from errors, it tries to skip a
token that fail to match the construct being parsed. If that still fails, it
will skip all tokens until it finds the start of a top level construct (i.e.
a statement like a rule, query, declare, etc) and resynch from there. If you
have too many different top level keywords, it increases the probability
that there will be a keyword clash and it will fail to resynch, resulting in
cobolish errors for the rest of the file... :)
I think I'll read the parser once more, with an eye out for recovery ;-)
-W
8:47 a.m.
Hehehe, always good to have your help. As you will see the skip one and
skip all tokens strategies are implemented. The "inject a token" and try
again is not, as that is a lot more complicated to do it and maintain
manually.
Edson
2011/7/27 Wolfgang Laun <wolfgang.laun(a)gmail.com>
On 27 July 2011 15:34, Edson Tirelli <ed.tirelli(a)gmail.com>
wrote:
>
> Just to explain how the parser recovers from errors, it tries to skip a
> token that fail to match the construct being parsed. If that still fails, it
> will skip all tokens until it finds the start of a top level construct (i.e.
> a statement like a rule, query, declare, etc) and resynch from there. If you
> have too many different top level keywords, it increases the probability
> that there will be a keyword clash and it will fail to resynch, resulting in
> cobolish errors for the rest of the file... :)
>
I think I'll read the parser once more, with an eye out for recovery ;-)
-W
_______________________________________________
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
4898
days inactive
4899
days old
6 comments
3 participants
participants (3)
-
Edson Tirelli -
Michael Anstis -
Wolfgang Laun