[antlr-interest] Somewhat tested optimizations to java.g - can anybody confirm correctness?

[Sander Mägi]

Hi

I tried to reduce semantic predicates in sample java.g.

I am pretty new to ANTLR and grammars in general.

Maybe somebody more experienced could confirm this is correct - (I have
already tested it with hundreds of kilobytes of code, but still)

thanks in advance,
Sander Mägi


change 1:
WAS: (declaration)=> declaration SEMI!
CHANGE TO: (modifiers typeSpec[false] IDENT)=> declaration SEMI!
BENEFIT: it also did variable initializers, that sometimes were quite long
(especially when defining anonymous inners, or ANTLR bitsets :)

change 2:
WAS:
unaryExpressionNotPlusMinus
 : BNOT^ unaryExpression
 | LNOT^ unaryExpression

 | ( // subrule allows option to shut off warnings
   options {
    // "(int" ambig with postfixExpr due to lack of sequence
    // info in linear approximate LL(k).  It's ok.  Shut up.
    generateAmbigWarnings=false;
   }
  : // If typecast is built in type, must be numeric operand
   // Also, no reason to backtrack if type keyword like int, float...
   lpb:LPAREN^ {#lpb.setType(TYPECAST);} builtInTypeSpec[true] RPAREN!
   unaryExpression

   // Have to backtrack to see if operator follows.  If no operator
   // follows, it's a typecast.  No semantic checking needed to parse.
   // if it _looks_ like a cast, it _is_ a cast; else it's a "(expr)"
  | (LPAREN classTypeSpec[true] RPAREN unaryExpressionNotPlusMinus)=>
   lp:LPAREN^ {#lp.setType(TYPECAST);} classTypeSpec[true] RPAREN!
   unaryExpressionNotPlusMinus
  | postfixExpression
  )
 ;

CHANGED TO:
castLookahead
 :
   LPAREN^ (typeSpec[true] LBRACE^ RBRACE^) |
   ( classTypeSpec[true] RPAREN^ (BNOT^ | LNOT^ |LPAREN^ | IDENT^ | "this" |
"super" | "new" | NUM_INT^ | NUM_FLOAT^ | CHAR_LITERAL^ |STRING_LITERAL^ |
"true" | "false" | "null"))
 ;

unaryExpressionNotPlusMinus
 : BNOT^ unaryExpression
 | LNOT^ unaryExpression

 | ( // subrule allows option to shut off warnings
   options {
    // "(int" ambig with postfixExpr due to lack of sequence
    // info in linear approximate LL(k).  It's ok.  Shut up.
    generateAmbigWarnings=false;
   }
  : // If typecast is built in type, must be numeric operand
   // Also, no reason to backtrack if type keyword like int, float...
   lpb:LPAREN^ {#lpb.setType(TYPECAST);} builtInTypeSpec[true] RPAREN!
   unaryExpression

   // Have to backtrack to see if operator follows.  If no operator
   // follows, it's a typecast.  No semantic checking needed to parse.
   // if it _looks_ like a cast, it _is_ a cast; else it's a "(expr)"
  | (castLookahead)=>
   lp:LPAREN^ {#lp.setType(TYPECAST);} classTypeSpec[true] RPAREN!
   unaryExpressionNotPlusMinus

  | postfixExpression
  )
 ;


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/