[antlr-interest] Complaints about BaseAST implementation

Akhilesh Mritunjai virtualaspirin at yahoo.com
Wed Oct 12 14:45:29 PDT 2005


Hi Andy

Thanks for the fast reply :)

The good news is that splitting is not even required.
Just move the fields and get/setFirstChild() and
get/setNextSibling to CommonAST and ParseTree classes
and its done and nobody's code will break if they
inherit from CommonAST. I doubt anybody directly
subclasses BaseAST because type and text are basic
properties that pretty much everyone needs, but even
if they do, they can add the two fields and four
getter/setter methods. It would be safe for them too
because rather than code silently breaking, now
compiler will throw an error.

--- Andy Tripp <atripp at jazillian.com> wrote:
> * You'll still want the "type" and "text" fields in
> the base class, I assume -
> I can't imagine an AST that doesn't need these

They're there only for ParseTree, ParseTreeRule and
ParseTreeToken classes... they don't need type or text
:) So I removed them from BaseAST and put them there.

> * I'm still having trouble picturing why you would
> want to implement
> these "down" and "right" fields any other way. I
> don't doubt that you need
> to do it, I'm just saying I can't picture it. So in

Well. One revealation. I work in an EDA tools starup
and am currently lead for developing a compiler and
analyzer for a leading HDL. The trees generated can
have 1-50 million nodes depending on type of input,
which of course I can't keep in memory because memory
requirements for tree alone goes into several
gigabytes. For that I have designed something that is
like a pluggable smart paging mechanism for tree
nodes... it breaks and reconstructs tree fragments on
the fly without ANTLR or our compiler knowing
anything. I can't reveal much without further
permission, but lets just say we're pushing ANTLR to
its limits :) Ah, and we are extremely happy ;-)

> the end, it may not 
> be worth
> it for Terrence to fold in this change, because you
> may be the only
> person who ends up needing/wanting it. I know
<snip>
> Making your change may
> be an improvement, but the current design has worked
> just fine for every 
> ANTLR user for many years, AFAICT.

It is ok. My obligation is just to inform about the
shortcomings I find while pushing the limits :)

One processor, 640kb RAM, petroleum burning cars etc
also worked for everyone for many years... until some
people pushed the limits (I know... bad analogies, but
I think the idea is clear) :-)

- Akhilesh



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/


More information about the antlr-interest mailing list