[antlr-interest] Re: Stuff I don't like about ANTLR 2.x /ANTLR 3 wants

[lgcraymer]

--- In antlr-interest at yahoogroups.com, "Richard Matthias" <richard at e...> wrote:
> Hi,
> 
> 1. The syntax for manual tree building. It looks an absolute mess with all
> those # and [] marks. I assume this is because it sits in with action code in
> the target language and you have to use syntax that won't clash with any
> language known to man. Because tree building is free it only increases the
> impact of the tree building syntax obscurity for occasional ANTLR users like
> myself. What I would like to see is some simple ANTLR specific syntax for
> tree building that exists outside the actions block.

That's coming in 2.8.  I've got the modified C++ backend to compile (half the problem) and just need to get my test cases to run (they 
work with Java).  Once that happens, I'll update my code to the match 2.7.3 final (pending) and a release should follow soon after.

> 
> 2. Different syntax for manipulating tokens in Lexer actions compared to
> manipulation of AST nodes in Parser actions. For example, in the Parser I can
> change the AST node class from "within ANTLR syntax", but I still have to use
> action code to change the node to use an 'imaginary' token. For example:-

Ter, Monty, and I briefly discussed adding an attribute (language independent AST specification) syntax in ANTLR 3 at the cabal.  It 
may happen.

> unary
> 	: PLUS^<AST=iASTUnaryOp>   {#PLUS.setType(UNARYPLUS);} unary
> 	| MINUS^<AST=iASTUnaryOp>  {#MINUS.setType(UNARYMINUS);} unary
> 	| atom ( PERCENT^<AST=ASTUnaryOp> )?
> 	;
> 
> Whereas in the lexer, I sometimes want to change the token and have to use an
> action (again), but this time have different syntax (it took me a while to
> work this out too when I first started with ANTLR on this project):-
> 
> LESSTHAN		: "<"		;
> LESSTHAN2		: "_lt_" { _ttype = LESSTHAN; };
> 
> (as an aside, I never really worked out why I couldn't use LESSTHAN: "<" |
> "_lt_"; here. It consistently produced nondeterminism errors no matter how
> much lookahead I allowed, yet this apparently equivalent construct works
> fine. Thankfully its easy to change the token type (once you know the magic
> syntax) so it didn't cause a major problem).

ANTLR 3 should fix this and have dramatically improved lexer speed as well.

--Loring



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
     antlr-interest-unsubscribe at yahoogroups.com

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