Good on you guys for looking at tiding up the confusing type hierarchies.
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 <[email protected]> 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
>
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
