[antlr-interest] lookahead DFA too big?

Andreas Meyer andreas.meyer at smartshift.de
Fri Mar 6 11:03:39 PST 2009


Paul Bouché schrieb:
> Hi,
>
> hi I also had this problem when trying to introduce a backward 
> compatible change into our Lexer. The problem with code too large... 
> It aggravated the heck out of me. Whenever I found a solution that did 
> not break the Java code size limit I got something which had here and 
> there less functionality than needed. I ended up giving up on the 
> project and arguing that it is not possible because it would break 
> current syntax (to my luck this is actually true).
>
> Anyway I never got around this problem and I still find it very 
> aggravating. I am not too exicited about the look-ahead mechanism 
> because if you have to look-ahead several charactes then make decision 
> you have to go back in the stream and then rematch those characters... 
> Also I tried to port a hand-written parser/lexer to ANTLR which used a 
> state table and some context sensitive decisions and was not able too 
> port this. First I ran into the code too large exceptions and then 
> into unresolvable amigiousties. Also semantic predicates do not help 
> too much because ANTLR still uses look-ahead in the presence of 
> semantic predicates - I would like to switch it off - how?? - if I use 
> semantic predicates I know what I am doing and I don't need ANTLR's 
> automatic analysis.
>

I also asked the question some time ago, and Terence said "no, it's 
probably not going to work". Unfortunately, he didn't include an 
explanation ... maybe it's too tedious to implement, maybe there are 
theoretical reasons against it ... dont know.

> As for you, maybe you can try to make your grammar ambigious and turn 
> on backtracking and memorization (for backtracking optimization). Of 
> course a backtracking grammar is slower than an LL(k)/* grammar, but 
> if you get what you want....

In my case, this only hides most of the error messages, leaving me with 
exactly one "predication DFA construction timeout" in a rule where I 
absolutely would not expect it :-/

Best Regards,
Andreas


More information about the antlr-interest mailing list