[antlr-interest] Re: Summary of ANTLR Issues

[lgcraymer]

Ric--

Comments below.

--Loring


--- In antlr-interest at yahoogroups.com, Ric Klaren <klaren at c...> wrote:
> Hi,
> 
> On Wed, Jul 09, 2003 at 06:05:45PM -0000, lgcraymer wrote:
> > Actually, immediate invocation of an AST method is something that 
> > ANTLR 3 probably won't support--we are likely to change the way 
ASTs 
> > are constructed to optimize away the problem of excessive AST node 
> > allocation (creating a node and then never using it).  The idea is 
> > that ANTLR would construct a list of AST operations (node 
creation, 
> > add sibling, make root) and then apply them at the end of a rule.  
You 
> > would have to have "MyMethod" called by the constructor.
> 
> Sounds like a good solution to getting rid of a lot of the action.g 
horror.
> Although you still have the problem of having to do two passes over 
an
> action to see which nodes are actually referenced? Or it might shift 
the
> problem to creating a set of AST operations that would get thrown 
away ?
> (But you guys probably thought of that ;) )

At this point, this is just an item for discussion this weekend--right 
now, we mostly have individual biases and have not even attempted to  
reach any agreements.  I'd like to see ANTLR-specific stuff--token and 
AST manipulation, tree construction--moved out of actions and into the 
antlr grammar.  That would make retargeting of both ANTLR and ANTLR 
applications easier.  With improved support for code generation, it 
should be easy to add these extensions.  This would probably mean that 
code would be generated for AST operations which might not be used; 
since they would mostly be get/set operators, they would be inline 
methods and cost nothing when not used.

> And you then have a way to specify that a certain AST type has 
different
> parameters?

Not yet--I haven't thought through possible syntaxes.  The first step 
is to convince Ter that this is the right way to go, and then worry 
about a clean syntax.

> Would it still be possible to label parts of the tree, so you can do 
stuff
> after it's been constructed? For some stuff a parser/treeparser 

I would think so--construction optimization is local to each rule, and 
rules would still return constructed subtrees.

chain is a
> bit overkill although it might depend on the amount of trouble it is 
to
> make such a chain in the new setup.

Creating the chain will be minimal effort--automatic tree grammar 
generation is a big help.  At this point, I have done enough work with 
diff3 that I'm pretty confident about code maintenance after 
regeneration of tree grammars.

> Will the new codegenerator lose the (ab)use of exceptions for 
parsing ?
> This eats cycles, and makes the binaries bigger in C++ mode. (And 
somewhat
> prevents targetting old C)

I don't know.  My guess is that Ter's template stuff will make it 
easier to write code generators, so this might become a target 
language issue.  [Right now, the XXXCodeGenerator.java files are so 
awful that you can't even consider such a paradigm shift for a target 
language.]  Exceptions are pretty natural for Java, but a late 
addition to C++.

> I wouldn't mind seeing some code generated by any prototype if 
available ;)

It will still be awhile.  I'm hoping that this will end up as an open 
source project with Ter as gatekeeper--with good design specs, the 
gatekeeper approach is a good way to take advantage of volunteer labor 
and still maintain consistency as to quality and appearance of 
developed code.  Ter's still wrestling with the dilemma of "I want to 
write it myself so that ANTLR does not become a gawdawful mess" versus 
"I really don't have the time".  That's not an easy decision to make.  
If we do go the open development route, we might see something by the 
middle of next year or earlier.

> Cheers,
> 
> Ric
> --
> 
-----+++++*****************************************************+++++++
++-------
>     ---- Ric Klaren ----- j.klaren at u... ----- +31 53 4893722  ----
> 
-----+++++*****************************************************+++++++
++-------
>   Wo das Chaos auf die Ordnung trifft, gewinnt meist das Chaos, weil 
es
>   besser organisiert ist. --- Friedrich Nietzsche


 

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