[antlr-interest] Complaints about BaseAST implementation

[Akhilesh Mritunjai]

Hi Terence and Micheal

I am attaching the diffs against 2.7.6b2 with this
mail. It works with one known bug. My comments to mail
are inline after the following description.

Changes are-
* Storage of child/sibling relationship data removed
from BaseAST. Algorithm code updated to use the
interface methods rather than data.
* Addition of option 'dupTree' (values, true/false,
default false, option has effect only when 'buildAST'
option is set to true) to Tree Walker grammar. This
option enables duplicating whole tree while only
processing and generating some nodes so that writing
full tree grammar is not required. So for example, you
can write a tree transformer that only walks
identifier declarations and loops and generates a new
tree with loops unrolled... writing grammar for other
constructs won't be required.

Bugs:
1. One known bug where if option 'ASTLabelType' is
used in conjugation with 'dupTree', in generated code,
code to for casting is not generated. So the output
doesn't compile. The workaround is to use the
ASTFactory and add following code-
///
ASTFactory factory = new ASTFactory();
factory.setASTNodeType(MyCustomNode.class);
mytreewalker.setASTFactory(factory);
///

My comments inline-

--- Terence Parr <parrt at cs.usfca.edu> wrote:

> 
> On Oct 12, 2005, at 5:57 AM, Micheal J wrote:
> > Perhaps BaseAST simply implements common
> algorithms for the  
> > CommonASTxxxx
> > classes. Anyone is free to design a new AST-Node
> class that  
> > implements the
> > behaviour specified in the AST interface.
> 
> Correct and correct. :)  BaseAST was meant simply to
> abstract out the child-sibling tree part so anybody 
> could subclass to add fields like string and token 
> type etc...  If you don't want a child-sibling, then
 
> implement AST.

Wrong and wrong impression :)

BaseAST is just a AST algorithms class. AST, by
definition is a tree. So there is nothing wrong with
child-sibling relation... it is fundamental to a tree
and at this hour I fail to see any other way a 'tree'
can be defined. So there is nothing like a 'If you
don't want a child-sibling'... they are required.
However, how I want to *store* this information about
child/sibling should be my choice! If I choose to have
half tree on this machine and half on another, with
info about remote child/sibling in a node with which
getNextSibling/getFirstChild can return the proper
object, be it so.

Again, subclassing AST would mean reimplementing the
15 algorithms that are coded there. That
reimplementation would be a 'copy-paste' job, makes
matter even worse.. the algorithms are perfectly fine
and are absolutely essential. One more correction -
the algorithms are not for CommonAST, they are for
AST. They work on basic AST interface contract and
have nothing to do with how the interface gets
implemented.

> That said, ANTLR 2 is a mess built under duress in
> my part time.   
> ANTLR3 is much better designed.  The v3 overview
> slides I'm building  
> for the workshop look good :)

OMG! If ANTLR 2.x is just a 'part-time' job, you're
god! ANTLR is one of the few good software I've ever
seen (I never laid my hands on a VAX on a PDP-11,
people say it was good too!). Many thanks for ANTLR
and string template :) We're all eagerly waiting for
ANTLR3.

- Akhilesh




		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new.diff
Type: application/octet-stream
Size: 13755 bytes
Desc: 3096160192-new.diff
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20051012/2ba55dfa/new-0001.obj