[antlr-interest] uh oh, thought of a good reason not to rewrite

[Thomas Dudziak]

> The choice appears:
> 
> 1. don't build a tree and you can use the efficient TreeNodeStream
> that doesn't buffer
> 2. DUP: build a new tree from the old tree; you can use the efficient
> TreeNodeStream that doesn't buffer
> 3. REWRITE: TreeNodeStream buffers the entire sequence of nodes to
> visit in the tree before parsing begins and nodes are rewritten not
> dup'd.
> 
> Come to think of it, there could be some really strange bugs
> introduced if you rewrite a subtree that is later parsed using it's
> original structure (but it no longer has that stronger and some of
> your actions will fail!).  Argh!
> 
> Anybody wanna comment?  This sounds complicated enough that I should
> release the tree parser component and worry about tree->tree
> manipulation for the next early access release.

I'm by no means an expert on this, but I can easily imagine scenarios
where you want to process the new nodes. For instance, when parsing
C/C++ style #define's, you probably want to do have one pass where you
only rewrite the tree to replace the defines with the makros contents.
In this case, it would make sense to process these new nodes
afterwards in the same step to catch any makros in the content of the
original #define.
How about making that configurable ? Antlr could easily mark new nodes
as being newly created in the current pass, and a local/global
configuration option could determine whether to process them or not.

regards,
Tom