[antlr-interest] Somewhat tested optimizations to java.g - can anybody confirm correctness?
Sander Mägi
sander at aqris.com
Fri Oct 5 06:38:19 PDT 2001
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/
More information about the antlr-interest
mailing list