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

[Terence Parr]

On Nov 16, 2004, at 3:29 AM, Alexey Demakov wrote:

>
> 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.

Agreed, so my point is that you cannot guarantee tree is correct <java 
1.5.

>>> 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.

Cool.  I look at this when I do the trees.

>> 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.

Yes, it looks very much like a grammar, right? ;)

>> 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.

Not true I'm afraid.  From your own manual, you have

abstract node Stmt
{
}

which does not describe what a statement looks like.  You must find all 
subclasses ;)

> 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.

Correct in this case.  See above though ;)  ANTLR can easily generate 
this type-based approach.

> 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.

Correct...this situation is because I think tree grammars are the only 
way to go except for simple cases such as the little visitor I 
demonstrate in the article (per my update just now).

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

Yes, a good tool to have.

Ter
--
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com
Cofounder, http://www.knowspam.net enjoy email again!





 
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/