[antlr-interest] TreeDL news: tutorial, new releases, mailing lists

Tiller, Michael (M.M.) mtiller at ford.com
Thu Oct 28 08:20:20 PDT 2004


> From: Alexey Demakov [mailto:demakov at ispras.ru]
> Subject: Re: [antlr-interest] TreeDL news: tutorial, new releases,
mailing
> lists
> 
> 
> Hi Michail
> 
> >   I find this TreeDL system quite interesting.  It is closer to the
way
> > I think than the typical homogeneous ASTs in ANTLR.  However, I see
a
> > couple of issues when comparing it to things I've done:
> >
> > 1) I notice that you do not utilize Generic collections (ala Java
1.5).
> > Is this something you are considering adding?  It would be a nice
touch.
> 
> I plan to implement translation to C# and Java 1.5 as fast as I can.

Cool.

> > 2) Your visitor pattern include "visitXYZ" methods.  I've found that
for
> > many structures an "enterXYZ" and "leaveXYZ" pattern is more
suitable.
> > In fact, one might argue that anything that has children would
probably
> > benefit from the "enter-leave" pattern (also found in SableCC if I'm
not
> > mistaken).  It doesn't matter for things like evaluation, but if you
> > want to output HTML (for example), it is nice.
> 
> Automatic tree traversing is not provided because there is no way to
suit
> all tasks.
> As you can see in interpreter visitor (step 5) I call visit methods
for
> children explicitly (through accept() of course).
> However, code generation library allows to visit children referenced
in
> patterns:
> 
> public void visitBinaryExpr( BinaryExpr node )
> {
>     txt( "${left} ${Sign:sign} ${right}" );
> }
> 
> Results of visit method for left and right children will be
substituted
> automatically.

Well, regarding the visitor pattern there are really two issues here.
First is the interface of the visitor.  The interface defines what
operations are involved.  This is where I think the "enter" and "leave"
methods would be preferable to a "visit" method for anything that has
children.  This has nothing to do with the tree walking itself (i.e. the
'accept' method invocations), it just provides a comprehensive list of
methods associated with each node type.  Looking at the documentation
you mentioned I see that TreeDL appears to do this part (although it is
restricted to 'visit' methods).

The second part is the tree walking part.  Here it is possible to write
tree walkers automatically but you have to choose a pattern (e.g.
depth-first).

My suggestion is to look at SableCC.  It does both of these things and
they I believe their scheme also allows for users to modify tree walkers
or create whole new ones with minimal effort.  It would be great if you
could provide much of the same functionality in your library.  If I
recall correctly, SableCC does something slightly different from your
scheme because the traversal pattern is not written into the node
definitions (I forget exactly what they do though).

> May be it is good idea to have a library of tree walker generators for
> particular  cases.

Precisely.  I suspect this will change the way you handle 'accept'
methods.  You would have to look at SableCC to see how they achieve
this.

> > 3) I could not tell from the documentation but it seems that (at
least
> > for children), you implement get methods.  Do you also implement set
> > methods?  Finally, are attributes handled similarly?  I like the
> > attributed tree idea, but I'd like some control over the get/set
methods
> > (to allow for things like cache invalidation, for example).
> 
> Translation scheme is described in TreeDL tool description
> http://treedl.sourceforge.net/treedl/treedl_tool_en.html
> Yes, get/set methods are generated for all children and attributes.
> set-methods also contain some checks to ensure correctness of tree.
For
> example, for lists with one or more elements
> list size is checked, != null is checked for all non-optional members
of
> reference type.
> 
> As described in TreeDL language description
> http://treedl.sourceforge.net/treedl/treedl_en.html
> you can insert additional code to get/set methods:
> 
> attribute <int> arrayIndex
> get
> {
>     Logger.log( "getArrayIndex() returns " + arrayIndex );
> }
> set
> {
>     if( arrayIndex < 0 || arrayIndex >= array.length )
>     {
>         throw new IndexOutOfBoundsException( "arrayIndex = " +
arrayIndex
> );
>     }
> };

Also very cool.

> Moreover, you can define your own way to store attribute value:
> 
> body
> {
>     int x;
>     int y;
> }
> 
> attribute custom <Position> position
> get
> {
>     position = new Position( x, y );
> }
> set
> {
>     x = position.getX();
>     y = position.getY();
> };

How do you deal with C# vs. Java differences?  (just curious...always an
issue for high-level schemes, like TreeDL and ANTLR, that allow embedded
code).  Do you just digest everything between the {}s and pass it
straight through?

> Also you can see at Calc.java generated from Calc.tdl
> Calc.java
>
http://treedl.sourceforge.net/examples/calc/treedl/com/unitesk/atp/examp
le
> s/calc/Calc.tdl-xref/index.html
> Calc.tdl
>
http://treedl.sourceforge.net/examples/calc/xref/com/unitesk/atp/example
s/
> calc/Calc.html
> And TDL.java generated from TreeDL.tdl
> TreeDL.tdl
>
http://treedl.sourceforge.net/treedl/treedl/com/unitesk/atp/treedl/TreeD
L.
> tdl-xref/index.html
> TDL.java
>
http://treedl.sourceforge.net/treedl/xref/com/unitesk/atp/treedl/TDL.htm
l
> 
> > 4) I didn't see this explicitly stated in your calc example, but is
the
> > interface for the visitor generated automatically?  If so, that is a
> > very nice touch.
> 
> Yes, visitor interface is generated automatically, it is at the end of
> Calc.java

I'm not sure I found Calc.java.  That probably would have answered most
of these questions.  Sorry about that.

> > 5) It isn't clear what the purpose of the "Syntax Grammar" section
is.
> > How is this used?  It seems like the tree definition + ANTLR grammar
is
> > pretty complete.  I don't see what the .bnf file is needed for.
> 
> As I mentioned in one of previos messages, we have BNF tool that
generates
> syntax tests
> from .bnf file. But primary usage of this file is documentation - it
is
> useful if language design
> and parser implementation are done by different persons.

Interesting.  So in some sense it provides independent validation of the
parser?  Does it generate cases to exercise all possible syntax
combinations or something?

> > 6) Your tree directive seems to be used to indicate what package the
> > eventual definitions will be included in.  Why not use the word
> > "package" instead of "tree".  To me, "tree" implies it has something
to
> > do with the data structures themselves rather than just their
location
> > in the package hierarchy.
> 
> TreeDL tries to be as language independent as possible. So "package"
is
> not good from my point of view.
> In fact it should be not "tree" but "tree desription" but it is much
> longer :(

Well, package is a pretty generic term.  Actually, it is used in all
languages that I'm currently working with (Java, Python and Modelica).
So I don't think it is overly language specific but the choice is yours.
It just wasn't obvious to me what it meant.

> > Items #1-4 represent differences between TreeDL and the way I have
been
> > approaching things.  I would be very interested in seeing how these
> > particular aspects of TreeDL evolve because I prefer your high-level
> > approach (so long as it includes the functionality I need).
> 
> It seems to me that TreeDL already have almost all you want (except
tree
> walkers may be) :)

Well, it sounds like #1 is coming soon, #2 is close but not quite what I
want, #3 is quite possible and #4 is implemented as well.  As I said,
quite interesting.  I'm not actively working on my parser at the moment
but I will definitely check on the status of TreeDL when I revisit it.

> > Looks very interesting.  Please keep us posted.
> 
> Thanks Michael,
> Glad to answer any questions.

--
Mike



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

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





More information about the antlr-interest mailing list