[antlr-interest] Re: Anyone tried this ANTLR-inspired CC?

Oliver Zeigermann oliver at zeigermann.de
Tue Nov 11 11:39:35 PST 2003


I think what Brian says is very reasonable given his type of 
application. His view concentrates on the semantics expressed by the 
design of his AST which is also implied in text disguised by synatx. Now 
, this syntax can change, semantics and thus AST remain the same.

However, your application could also be translaton from one language to 
another with a different syntax, but identical or only slightly 
different semantics. If this translation is complex it is very 
convenient to do this in more than one step using ANTLR tree 
transformation. In this scenario ANTLR-ASTs are the best you get. You 
have full control over what nodes are copied, deleted or moved. 
Remember, you can also do successive ANTLR-AST to ANTLR-AST 
transformations by which you can refine what you want in a convenient 
way. Finally, you can dump the whole ANTLR-AST to your destination 
syntax. I have done this very successfully with XML data that fits 
perfectly in ANTLR-ASTs.

Oliver

brian-l-smith at uiowa.edu wrote:
> Quoting "Tiller, Michael (M.M.)" <mtiller at ford.com>:
> 
>>>From: Terence Parr [mailto:parrt at cs.usfca.edu]
>>>On Sunday, November 9, 2003, at 05:37 PM, leung13512c wrote:
>>>
>>>
>>>>The thing that caused me to switch away from ANTLR syntax
>>>>is because I prefer the tree building syntax of JJTree that always
>>>>create imaginary nodes instead of a mix of both.  And it mostly
>>>>avoid having to create nodes within actions.
>>>
>>>Howdy.  This is the old AST versus parse tree argument...Parse trees 
>>>are easy to generate (i.e., no cost to developer) but have 
>>>way too much noise for tree transformation and also are sensitive
>>>to grammar construction whereas ASTs are the canonical repr for
>>>a particular language.
>>>
>>>Ter
>>
>>Personally, there are two extremes I would like to avoid.  One is using
>>terminals as roots in ASTs.  I don't really care for this approach because I
>>find it rather strange (just my personal preference).  The other case I
>>wouldn't like is having every production rule in my grammar generate a node
>>in my AST.  As far as I'm concerned, these are both sub-optimal.
> 
> 
> I agree with Mike. I never use ANTLR's AST features because they aren't really
> for *abstract* syntax trees--they are really a kind of *concrete* syntax tree
> (similarly, parse trees ala JJTree are *concrete* syntax trees). This is easy to
> see because the resultant tree is built using elements of the concrete syntax
> grammar. An *abstract* syntax tree is independent of the concrete syntax of the
> language. In fact, usually I create a syntax-independent domain model of the
> language (e.g. with classes representing all the major concepts of the
> language), and then create an ANTLR grammar that can parse a syntax that allows
> one to express these abstract concepts textually. If you develop a language this
> way then the ANTLR "AST" mechanism is basically useless. But, IMO, this is the
> most sensible way to develop a language tool, because once you have the domain
> model built you can have one team work on the concrete syntax (text -> AST) part
> of the project while concurrently another team is working on the semantics (e.g.
> AST evaluation, translation). 
> 
> Terence made the point that ANTLR's "AST's" are better than JJTree-style parse
> trees because the resultant trees are less sensitive to changes in the grammar
> used for parsing. But, changes in the concrete syntax of the language, and/or
> changes in the grammar used to parse it, still can easily reshape the resultant
> "AST" unless one is very careful. But, the AST-first approach completely
> isolates all grammar/syntax changes from other parts of the project.
> 
> So, I guess what I would like to see is a mechanism for specifying a
> syntax-independent ("abstract") domain model of a language, a mechanism for
> specifying how to parse concrete textual representations of the language
> (grammars), and a mechanism for translating between textual representations and
> the abstract domain models (either one-way text -> AST, or bidirectional text
> <--> AST).
> 
> Regards,
> Brian
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
> 




 

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




More information about the antlr-interest mailing list