[antlr-interest] Using Tree Interface not plain Object

[Sam Harwell]

The new interfaces aren't required across the board, but would be used for
the vast majority of situations. By specifying the "ASTLabelType=xxxxx;" and
"TreeAdaptorType=yyyyy;" options, you could override the entire system.

This restructuring primarily affects the arguments and return values from
various methods in the Tree and TreeAdaptor interfaces. Also, the new
interfaces are MUCH simpler than they used to be. Methods which alter the
tree are all moved to and unified in the TreeAdaptor, and many of the
utility-type methods are moved to a new module instead of requiring every
tree implementation to implement them.

The previous interfaces were large, confusing (do you call tree.addChild or
treeAdaptor.addChild?), and severely restricted my ability to create generic
trees and a general purpose tree visualizer (similar to STViz but for parse
results).

Sam

-----Original Message-----
From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Oliver Zeigermann
Sent: Sunday, September 04, 2011 2:49 PM
To: Terence Parr
Cc: Antlr List
Subject: Re: [antlr-interest] Using Tree Interface not plain Object

What would be the benefit of introducing and then requiring those
interfaces? Might make sense when you want to do automatic tree traversal,
but maybe not when you want to create any kind of object where you might not
even have a (single) parent or a flat list of children. Would it be possible
to have both? Tree interfaces for homogeneous, normalized trees that can be
processed further using ANTLR and whatever you want to generate if you do
not want further ANTLR processing?

- Oliver

2011/9/4 Terence Parr <parrt at cs.usfca.edu>:
> Hi. Currently v3 requires nothing of your tree nodes; all you have to do
is give me an adapter that says how to create them and navigate them and
manipulate them. Users can set up ASTLabelType as an option so that $x in
actions has the user's type instead of plain object.
>
> Sam Harwell and I were talking today about restructuring all of the tree
interfaces. We're breaking it up into a hierarchy with Tree interface at the
top. Tree just says you can get a payload, some children, and parent.
ParseTree and AST split off as sub interfaces. We were thinking that it's
pretty silly to use simple object when we could require the minimal Tree
interface so at least code could display or navigate them. The reason I went
with plain object originally was so people could use any existing object
they have, even if they only have binary for it. This seems like a fairly
extreme example and, in the worst case, somebody could wrap those objects so
they were suitable for use with ANTLR. More than likely, somebody in that
situation would simply use actions to construct the trees they want. Most
trees not built for antlr expect everything in the constructor, whereas
antlr has to build up the trees piecemeal as it parses.
>
> So, does anybody object to ANTLR assuming Tree in the parser if you are
building trees and then AST in the tree parsers?
>
> Ter
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: 
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>

List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address