[rules-dev] RFC: declaration syntax

Edson Tirelli ed.tirelli at gmail.com
Wed Jul 27 09:34:14 EDT 2011


   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 at gmail.com>

> On 26 July 2011 21:28, Edson Tirelli <ed.tirelli at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>


-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110727/1ad7d5de/attachment.html 


More information about the rules-dev mailing list