[antlr-interest] ANTLR-based Java grammar for javac compiler

[Andy Tripp]

Yang Jiang wrote:
> Andy Tripp wrote:
>> This seems like a good goal for the new ANTLR tree rewrite mechanism.
>> Given the problem of converting a "whatever the java.g author thought
>> was reasonable" AST to a "exactly what javac needs" AST, if the
>> rewrite mechanism can make this easier than just "doing it by hand", then
>> it will be a "good" mechanism, and not just a toy.
>>
>> Having said that, it looks to me like none of the tree rewrite software
>> (e.g. TXL) out there are "good". In other words, they don't look to me 
>> like they
>> are saving anybody any work, even for this typical use case.
>>
>> I'm sure Terence could use ANTLR treewalkers to do this pretty quickly,
>> but I wonder if Jiang could, too.
> Hi Andy,
> I agree with you that rewrite from on AST to another AST could be hard :)
> 
> But what Simon was saying is to use the Antlr tree rewrite + a custom 
> TreeAdaptor to build
> the javac tree directly, rather than using the Antlr tree built from the 
> tree rewrite grammar with a tree walker,
> then generating the javac tree.

So there are 4 potential approaches:
1) ANTLR parser with rewrite + TreeAdaptor
2) ANTLR parser + ANTLR treewalker
3) ANTLR parser + some other AST rewrite system
4) ANTLR parser + handwritten code to transform AST

I think Simon's question is "is there any easier way than #4?"
And my answer is "No" with a strong hint to Terence that it sure would be nice
if #1 or #2 would make that answer "Yes."

> 
>>
>> Yang Jiang wrote:
>>> Yeah, that is the reason.
>>> The javac tree is more than just nodes, it also has info like 
>>> position, javadoc and line maps etc..
>>> It would be pretty easy to simply use the Antlr tree rewrite to build 
>>> a tree, but not that easy if
>>> the tree structure/specification has already been defined.
>>
>> When is the tree structure that you need to produce NOT already defined?
> For example, the javac node for Compilation unit has three children : 
> package annotations, package declaration,  definition list(including 
> types imported from "import" and class/interface/enum declaration).
> 
> The Java.g grammar I used , from here 
> http://antlr.org/grammar/1152141644268/Java.g, defines compliationUnit 
> like this:
> 
> compilationUnit
>    :   annotations
>        (   packageDeclaration importDeclaration* typeDeclaration*
>        |   classOrInterfaceDeclaration typeDeclaration*
>        )
>    |   packageDeclaration? importDeclaration* typeDeclaration*
>    ;
> 
> 
> importDeclaration is NOT part of typeDeclaration here.
> Of course, I could tweak the rules to make it generate what I need, but 
> it'll just make the grammar hard to read. Besides, I don't want to write 
> another Java.g  myself:)

What I meant was that this is always the case for many real-world applications -
you don't get to decide what the end AST should look like. For some simple
applications, the shape of the AST produced by the given java.g will be "close enough".

I guess I'd just love to see Terence to for AST rewriting what he did for parsing:
raise the level of whole playing field :)

> 
> 
> Yang
> 
> 
>