[antlr-interest] ANTLR-based Java grammar for javac compiler
Andy Tripp
antlr at jazillian.com
Fri Nov 14 07:35:03 PST 2008
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
>
>
>
More information about the antlr-interest
mailing list