[antlr-interest] Re: summary of trip to Montreal/SableCC land

[Alexey Demakov]

From: "Terence Parr" <parrt at cs.usfca.edu>
> Well, it can do some but not all; you have to be very very careful with 
> types.  For example, I just finished somethign in my little article 
> about lists of children such as argument lists.  Unless you use 
> List<Argument>, you cannot guarantee anything about tree structure.

Yes, but why to run ahead of locomotive? :) We should be consistent with
features that target language offers. When target is Java 1.5 
(oh, sorry, Java 5 :) ) or the next version of C# we can use new features.
In the current Java it can be an option - checking list member types 
in node constructor. Or ability to use list type that checks element type.

> > Depending on the differences between the input and output tree
> > structures and how many of them we have, I can see that the
> > heterogenous approach may become unwieldy at some point. I still feel
> > ANTLR needs to support both.

Now the interface of node factory used by ANTLR is not sufficient to build
hetero-trees. But changes required to support it are very small - add node 
type as part of creator method name, i.e. factory.createSomeNode(...)
instead of create(...) now. At least factory.create( SomeNode.class, ... ).
And translate #() parameters as create() parameters, not add() calls.
(I use create(), not make() because it is mentioned in ANTLR docs).
In fact, is not much shorter than manual calls of tree factory in actions.

> I agree.  Sometimes hetero trees are nice. :)  For big translations, 
> however, 500 node types just adds complexity.  You should focus on tree 

200, not 500. 500 nodes means more than 500 grammar rules.
I think, language that requires 500 nodes in well-designed AST
is unusable :) 

And when these 200 nodes are described in a single file (or several
- to separate statements, expressions, high level structures etc)
with only one line for each child/attribute - it is quite useful.

> structure.  Type systems are blunt instruments for specifying 
> structure. ;)

Type system is not sole instrument. Structure description of hetero-tree 
is equivalent to tree grammar. Compare

    binary_expr : l = expr s = sign r = expr ;

and

    node BinaryExpr : Expr
    {
        child Expr left;
        attribute enum { PLUS, MINUS, MULT, DIV } sign;
        child Expr right;
    }

The difference is in generated code. For ANTR all information is in 
"smart" tree parser. For hetero-tree description (of course, I use TreeDL :) ) 
- it is tree node classes with all possible information about tree structure
and ability to generate additional systematic code (visitor interface 
and implementations, tree walkers and all that can be generated using tree description)
to implement actions over tree.

So, I see drawback of ANTLR tree data model - It can be used ONLY with tree parsers
because of pain of getting correct child position. And no one existing IDE will help you.
In contrast, when there are get/set methods for each child/attribute it is possible
to use code completion to speed up development.

> >>> Btw, I begin to understand that separate tree description is
> > closer to
> >>> ANTLR
> >>> tree parsers than I thought before...
> >>
> >> :)  Hooray!

You see, I've explained it above.

> > Except for the fact that separate tree description supports the use of
> > hetero-nodes much better than ANTLR currently does.
> 
> ANTLR supports general "ID should become IDNode" level support as well 
> as individual reference ID<AST=IDNode> hetero specs.  What else would 
> you like?  I'll start thinking about it when I get to trees. :)

My thoughts are above - alternate #() translation.

> >>> But what if I need more that one pass over tree - should I repeat
> > tree
> >>> grammar
> >>> in each tree walker? I don't like to have same info more than in one
> >>> place.
> >>
> >> Agreed.  You have identified something that uses up lots of my spare
> >> "CPU" time.  One solution is to simply use a tree grammar to call
> >> action methods and then you can subclass the tree parser. Now, you are
> >> back to the visitor idea and don't have to repeat the tree, however,
> >> this is unsatisfying as I've said.  I believe that we need a model
> >> where you can cut/paste a grammar to multiple phases and then push
> >> updates to all phases when the structure changes.  In reality, this is
> >> called RCS (diff3).  For papers, i'll make up some fancy name ;)

At least, ANTLR should provide tree grammar comparision to make sure
that all changes were propagated, manually or automatically.

> Yes, a tool that lets you derive a new pass from a "template" grammar 
> is what we want. :)  I think diff3 that is ANTLR grammar based not text 
> based will do nicely :)

Is it similar to making html docs from parser description? :)

Regards,
Alexey

-----
Alexey Demakov
TreeDL: Tree Description Language: http://treedl.sourceforge.net
RedVerst Group: http://www.unitesk.com





 
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/