[antlr-interest] Summary of ANTLR Issues

[Tiller, Michael (M.M.)]

> -----Original Message-----
> From: Ric Klaren [mailto:klaren at cs.utwente.nl]
> Subject: Re: [antlr-interest] Summary of ANTLR Issues
> 
> On Mon, Jul 07, 2003 at 01:22:30PM -0400, Tiller, Michael 
> (M.M.) wrote:


> > 1) There is a major bug in 2.7.2 that prevents you from 
> cloning hetero ASTs
> > in C++ (another indication that most people use homogenous ASTs).
> 
> Do tell ;) I must admit that while I made the cloning stuff I 
> probably did
> not think of all possible uses in the support lib and stuff 
> so maybe you
> stumbled on something I overlooked.

This was mentioned previously by someone else in the group.  I just implemented what they suggested.  It just meant changing this:

  AST(const AST& other) : ref(other.ref->increment()) {}

to this:
        
  AST(const AST& other) : ref(0) {}

> > 2) Even though I can associate heterogeneous types with tokens, ANTLR
> > doesn't respect them for synthetic tokens.  By "respect" I mean that it
> > doesn't generate the appropriate factory initialization code (there is a
> > workaround for this by creating a dummy rule that utilizes the synthetic
> > tokens as terminals) and it doesn't allow you to operate on specific
> > members and methods for your heterogeneous ASTs in the production rules
> > (because you have to manually create them so it has to use the factory and
> > therefore uses a generic interface).  The former is what I was eluding to
> > at the end of the previous section on synthetic nodes.
> 
> If you could supply me with a small compileable grammar written as you
> would expect things to be handled (no workarounds) then I can 
> have a look.

The problem is, what I want won't compile.  Well, at least if I include everything I want it won't compile.  I'm attaching two versions of "treewalk.g" from the "imagNodeAST" example (for C++).  The first version will compile (in the ANTLR sense at least) but fails during C++ compilation because ANTLR uses a generic interface when I want it to be smart enough to use the specific interface.  Another version addresses something you mention later on...

> > I think that with the exception of the C++ class hierarchy, 
> much of this is
> > easy to address.  Looking at my grammar, things would be 
> greatly simplified
> > if the following were possible:
> >
> > 1) Automatic construction of synthetic nodes via a syntax like:
> >
> > declaration<AST=DeclarationNode>
> >   : type name ";"
> >   ;
> 
> Personally I'd wait for Loring's stuff before adding stuff 
> like this. (I don't mind the ## = #( .. ) syntax too much) Maybe I'd go for Monty's
> suggestion of a macro facility in antlr then it would be easy 
> to make some sugar for this.

I'm using the ##=#(...) trick now.  That isn't so much of a burden.

> > 2) Ability to reference heterogeneous methods and members , e.g.:
> >
> > declaration<AST=DeclarationNode>
> >   : t:type name ";" { ##->setType(t->getTypeName()); }
> >   ;
> 
> I do not follow, this should already be supported. If it's not working it's
> a bug.

I think you misunderstand me.  If I specify an AST for a *TOKEN*, e.g.

tokens {
  BLOCK<AST=My_AST>
}

Then I'm OK so long as BLOCK isn't imaginary.  If it is imaginary, you need to create a dummy rule to get ANTLR to generate the appropriate 

> 
> > 3) Definitions of custom AST types should involve a minimum of code.
> 
> Agree.

I modified the treewalk.g file from the imagNodeAST example for C++.  You could be able to save these files in that directory and (assuming you can build the baseline example), simply rename this files to "treewalk.g" and see the issue list for each one.  Here is a breakdown of the included files:

MyAST.hpp:

  Needed to compile this stuff

treewalk1.g:

  This shows how heterogeneous ASTs should be created and used.  There are two problems with this version.  First, the factory initialization is not done correctly.  Second, I cannot access a specific method on my heterogeneous AST.

treewalk2.g:

  This version generates an appropriate factory initialization (by using the workaround of adding the dummy rule where BLOCK appears as a terminal in the rule).  Note that this version still suffers from the problem that the hetero specific method is still not accessible in the "block" rule.  I don't think this is a bug, I think it is impossible as long as you manually build the node.  This is because the manual construction relies on the factory interface which is generic.  I suppose you could inspect the "BLOCK" type and then add a cast at this point or circumvent the factory somehow.

treewalk3.g:

  This shows how I would like to do (i.e. associate specific AST types at rules).  You mention above that you think this is a bug if it isn't supported.  I would point out that ANTLR cannot compile this and I see no mention of this particular syntax in the ANTLR documentation.  As such, I don't think this is a bug...ANTLR simply cannot do this (currently).

--
Mike


 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MyAST.hpp
Type: application/octet-stream
Size: 1092 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20030708/10fcd531/MyAST.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: treewalk1.g
Type: application/octet-stream
Size: 1618 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20030708/10fcd531/treewalk1.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: treewalk2.g
Type: application/octet-stream
Size: 1643 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20030708/10fcd531/treewalk2.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: treewalk3.g
Type: application/octet-stream
Size: 1668 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20030708/10fcd531/treewalk3.obj