[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