Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug? Option FORCE_LA_CHECK is unaware of option LOOKEAHEAD

38 views
Skip to first unread message

rfgi...@gmail.com

unread,
Nov 14, 2013, 9:14:37 AM11/14/13
to
I believe I have a bug report, but it doesn't seem reasonable to file a new issue in JIRA. So I'm submitting it here.

Please help me understand whether this is an actual bug and if an issue should be filed for this.


------------------ 8< ------------------


Environment:

Debian GNU/Linux
Linux ********** 3.10-3-amd64 #1 SMP Debian 3.10.11-1 (2013-09-10) x86_64 GNU/Linux
java version "1.7.0_21"
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-5)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

Description:

The options LOOKAHEAD and FORCE_LA_CHECK do not work together in a reasonable manner.

Consider the following simple grammar, expressed as regexp EBNF:

s = (a | b)*
a = "x" "y"
b = "x" "z"

While this grammar could be easily transformed from LL(2) to an LL(1), this is to intended to be taken as a simple example for situations that may appear in a more complex scenario.

Using a LOOKAHEAD(2) or globally setting LOOKEAHEAD=2 should ensure proper parsing of this grammar. However, this will leave the user without the assistance of Java CC to ensure their grammar is indeed LL(2).

Java CC suggests using the option FORCE_LA_CHECK. However, the usage of this option will cause Java CC to continue issuing warnings and suggesting the user to set a lookeahead of 2 or more -- even though that's what brought them to setting FORCE_LA_CHECK in the first place.

It seems that the option FORCE_LA_CHECK causes Java CC to always expect an LL(1) grammar, regardless of any LOOKAHEAD declarations.

What should be expected: when LOOKAHEAD is set to K, Java CC, at least when issued an explicit FORCE_LA_CHECK, should issue warnings only if the choice ambiguity cannot be solved with a lookeahead of K tokens.
0 new messages