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