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.l...@gmail.com>
> On 26 July 2011 21:28, Edson Tirelli <ed.tire...@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
