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

[Alexey Demakov]

From: "Terence Parr" <parrt at cs.usfca.edu>
> 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.

I can. But didn't think it's necessary. Ok, I'll add an option to generate
such checks.

> >> 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? ;)

Of course :) And '?', '*', '+' in tree description emphasize this fact.
But tree description is primary data description. And requires additional
notation for actions. In contrast to tree grammar it is not required
to redescribe tree structure in action descriptions.

> >> 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 ;)

Good documentation with cross-references helps. In any case, it is usual situation
for OO languages :) I often look in JDK JavaDocs to find required implementation of
OutputStream or something.

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

Another thought: Is it possible to write partial tree grammar?
If I need to go from root node to some known subtree and don't want
to specify other parts of tree? Can I write something like

rule : #(ROOT unknown unknown child unknown) ;

child : #(CHILD unknown unknown anotherChild) ;

anotherChild : #( ID ) ;

unknown : ???

Or I should inherit this small tree grammar from full one?
In any case, will ANTLR walk entire tree?

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/