[antlr-interest] Re: OO design question

lgcraymer lgc at mail1.jpl.nasa.gov
Thu Jun 13 15:59:01 PDT 2002


--- In antlr-interest at y..., Terence Parr <parrt at j...> wrote:
> 
> On Thursday, June 13, 2002, at 02:20  PM, Trey Spiva wrote:
> 
> >>
> >> So!  How do you get a good separable chunk called an Analyzer 
without
> >> making the implementation fully of crappy switch-statements?  
I.e., how
> >> do I use aspect programming w/o losing the polymorphism 
convenience?!
> >> Anybody wanna lend me some smarts?
> >
> > Have you thought about using a Visitor Pattern?
> 
> I think a visitor is really what i'm talking about; perhaps I'm 
asking 
> about a good way to implement it :)

Ter--

Sorry, Ter--I can't resist.  "Use the Force, Luke".  The current 
implementation approach for analysis works; just change GrammarElement 
classes to AST classes (and these could be generated with a little 
language).  The lookahead engine in ANTLR _is_ somewhat monolithic:  
each of the GrammarElement subclasses has a lookahead method that 
invokes
        grammar.theLLkAnalyzer.look(k, this);
(that works for AST classes, as well) and there are then a set of
        look(int, <class>)
methods in LLkAnalyzer.java.  All you need to change the analysis 
right now is to subclass LLkAnalyzer and change the code in Tool to 
use the subclass analyzer.

The current mechanism is okay if you just replace GrammarElements with 
heterogeneous ASTs; however, LLkAnalyzer is a mess (whimper, whimper). 
 Also, I think that it would be neater bind the analysis code to ASTs 
via specification:  they you can just copy (via treewalker) the 
analysis tree to one which has ASTs with different analysis methods.  
A good use of your output grammar stuff ... 

--Loring 

> 
> Thanks,
> Ter
> --
> Co-founder, http://www.jguru.com
> Creator, ANTLR Parser Generator: http://www.antlr.org


 

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



More information about the antlr-interest mailing list