[antlr-interest] Re: alternative prediction mechanism for 3.0

[antlrbrian]

--- In antlr-interest at yahoogroups.com, Ric Klaren <klaren at c...> wrote:
> Terence wrote:
> > DFA decision = dfaFactory.get("...DFA description...");
> 
> You mean to have a 'high' level ASCII DFA specification of
> states/transitions etc. between the ".." or just an id for tha
> specific DFA?
> 
> Why not encode the DFA in static tables (that can be 'run'
> directly without first processing them)?
> There's lot's of ways to do that if I recall right.
> It also offers the possibility to dump the tables in separate
> class files (if size becomes an issue).

Why not generate the DFA to a textual representation, and then compile
that textual representation to bytecodes. My thinking is:
1. The DFA textual representation will be easier to read than
   generated Java code.
2. Using the new Java debugging API's (JSR 45), the classfiles
   can be generated in such a way that debuggers can trace
   through the DFA's textual representation directly.
4. The JVM GOTO instruction (and other such things) can be used
   to speed things up if necessary.
5. It is a good demo of ANTLR's ability to generate tools
   that generate binary output. I've only seen source-to-source
   or source-to-AST translators in ANTLR.

- Brian




 
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/