[antlr-interest] Using Tree Interface not plain Object

[Terence Parr]

On Sep 4, 2011, at 5:24 PM, Gary Miller wrote:

> Good on you guys for looking at tiding up the confusing type hierarchies.

Yah,  they got pretty cluttered and messy over the years. Sam Harwell is a stickler for these kinds of details and really helping me think about how the API should look.

I'm going to leave the tree node type as object, so there really is no kind of limitations. you just passing your tree adapter and tell me how to create and navigate trees.

We will definitely assume generics level Java minimum.

Ter
> 
> One thing I tried to do was use a centralised tree structure for part
> of an AST and the default distributed one for the rest.
> Would your proposal make any difference to this issue?
> I haven't spend much time on it and therefore haven't come to a
> conclusion as to how hard this is.
> The reason I wanted to do this is that the syntax represents a tree
> structure and the data structure being used in the rest of the code is
> a centralised tree structure.
> I wanted to build it once, instead of haven't to walk a distributed
> tree just to build a centralised one.
> 
> As an aside, on the Java front can v4 set 1.5 as a minimum and use generics?
> Also "Item 16: Favor composition over inheritance" (Effective Java 2nd
> ed) would help keep things tidy.
> 
> Regards
> Gary
> 
> 
> To be a bit more concrete re centralised vs distributed:
> 
> Centralised tree
> ================
> class Axis {
>  Map<Node,List<Node>> parent2Children;
>  Map<Node,Node> child2parent;
> 
>  void addChild(Node parent, Node child) { ... }
>  etc
> }
> class Node {
> }
> 
> 
> Distributed tree
> ==================
> class Node {
>   Node parent;
>   List<Node> children;
> 
>   void addChild(Node child){ ... }
>   etc
> }
> 
> On Mon, Sep 5, 2011 at 5:22 AM, Terence Parr <parrt at cs.usfca.edu> wrote:
>> 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
>>