1

Question: is there a (more straightforward) way of building custom parse trees at parse time in ANTLR v4?

I guess that one could traverse and rewrite the automatically built tree but I was wondering if we can still do manual tree building (or tweaking, for that matter) at parse time (similar to ANTLR v3 and ealier). The idea is that, depending on how one writes his/her grammar, we get a lot of useless nodes in the ANTLR-built tree and while I get it that you can override only the listener methods that interest you, one still has to check and skip useless token types, etc.

Improve this question

2 Answers 2

Reset to default
3

No, our experience with ANTLR 3 is the manual AST feature inevitably resulted in code which was more difficult to maintain and understand, leading to a high rate of regression bugs for developers making any change to a grammar. Tokens are no longer omitted from the tree since it's difficult to tell which terminals will be needed by future releases of an application, and you don't want to have to change/verify all of your code operating on the parse tree if a terminal which was previously unused is now required by a new component or feature.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thanks for the clearing up! You do have a strong point with leaving client code untouched when you change / reorganize some grammar rule... I was thinking from a performance perspective but I guess the overhead is usually close to nothing.
@OctavianTheodor The current design of ANTLR 4 has not proven to be a significant performance limitation under my evaluations, and this is something I all but obsess over. Other areas, including the actual structure of the rules themselves (lookahead, ambiguity, etc.) always have a more pronounced impact.
2

You can override org.antlr.v4.runtime.Parser.addContextToParseTree() to get some control over what nodes get created. Not sure this is quite what you mean by custom.

@parser::members { @Override protected void addContextToParseTree() { // code is a rule enabled by semantic predicate 'full' // that matches generic lines of code. if(!full && _ctx instanceof CodeContext){ return; } // otherwise add the node to the tree.. super.addContextToParseTree(); } }
Improve this answer

2 Comments

Thanks! While I've moved on from that 'issue', this seems indeed a nice catch. (haven't actually tried it yet but by checking github.com/antlr/antlr4/blob/master/runtime/Java/src/org/antlr/… I'd say you are right!)
No worries - it does seem to be working for me so far - my application caches parse trees, and since I only need them for symbol table info (function/variable definitions) the ability to create a sparse tree is saving significant space/time.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.