[antlr-interest] Return values from listener methods (was "Appropriate use of honey badger listeners")

[Oliver Zeigermann]

2012/1/14 Terence Parr <parrt at cs.usfca.edu>:
>
> On Jan 14, 2012, at 4:39 AM, Oliver Zeigermann wrote:
>
>> Obviously, we have different ideas how to use the parse tree. If I did
>> something like a static type computation this clearly would be beyond
>> the scope of a parse tree for me.  For a project like this I would use
>> a heterogeneous AST and a custom visitor that could easily contain
>> this type of information.
>
> Given that expression trees are now so simple, just expr rule notes and tokens, I think I would just stick with the automatically generated tree. ASTs are gone from honey badger anyway.

I agree to stick to parse trees if the task is rather small.
Concerning ASTs: even if there is no support for it in ANTLR4 they
still can be created from ANTLR4 and I guess some people - including
me - will do see (see below) ;)

> I would definitely want to store the type associated with each Subtree. I think it would be natural to store it in the nodes themselves, but obviously some kind of a hash table to decorate a tree would work.
>
> How happy are you with your custom AST construction from the listener events?

I am happy with it, but not sure if other people would.

Given this grammar

http://code.google.com/p/antlr4-ast-visitor-sandbox/source/browse/trunk/src/parser/v4/ExprV4.g4

my listener code to create a custom AST looks like this

http://code.google.com/p/antlr4-ast-visitor-sandbox/source/browse/trunk/src/parser/v4/V4ExpressionParserListenerStyle.java

Fairly simple and straight forward, but maybe only in my eyes.

>> But this is a matter of definition I guess. If I wanted to do this
>> kind of thing, I agree, there should be a way of extending the
>> context. AFAIK right now the only way to define a context is via the
>> grammar.
>
>  currently, yes.
>
>> Could it be possible to extend theses contexts manually (by
>> subclassing) and tell ANTLR to create a custom context instead of the
>> generated ones? I lost track of the ongoing discussion a little bit,
>> so if this has been proposed already, please be lenient toward me :)
>
> The factory complicates things a little bit because now I have to generate a factory automatically. I guess the factory would map a rule index to the proper context object to create.

Right. But what would be the alternative?

- Oliver