On Thu, 15 Jul 2010, Wilson Snyder wrote: > Thanks, yes > > %define lr.keep_unreachable_states
Oops, yes, that's how you spell it in 2.4.2. 2.5 will provide the nicer spelling (dashes instead of underscores), but the old spelling will be supported indefinitely. > works around the issue. However, this source code is open > sourced, and runs against many versions of bison. Presuming > for a moment I wanted to really use this define, how would I > prevent this define from causing a syntax error on earlier > versions? You could extend your project's configure script to check for this feature. It could then transform grammar.y.in into grammar.y by replacing @BISON_KEEP_UNREACHABLE_STATES@ with either the above directive or the empty string. > More importantly, I still don't see why these rules are > useless. Can you or someone please take a look at the > grammar? I'm afraid I don't have time at the moment, but maybe I can make some helpful suggestions.... These rules are useless because they appear in unreachable states. A state becomes unreachable when a S/R conflict is resolved as a reduce or as an error and when the shift was the last way to reach that state. Currently, Bison does not detect states that become unreachable due to the removal of reduces, so you can be sure that's not the cause. I think you named about 6 states that are removed. I recommend you comment out all precedence declarations in your grammar and then generate the automaton report with --report=all. Next, search the report for states that have shift actions to the states that were previously removed. Those states represent the contexts in which the decision is being made to discard the rules. > Also, is there some way to get more verboseness in why a > rule is considered useless - what it overlaps against, for > example, in the way that reduce-reduce conflicts do? > Otherwise it's extremely hard to figure out what's wrong in > a grammar this size. Unfortunately, Bison doesn't produce any additional information at the moment. A helpful starting point would be if Bison could list example token sequences that lead to any particular state. This would help users to understand what context a state represents once they've identified states using a procedure like the one I described above. However, Bison can generate its automaton report in XML, which should make it easier to write helpful analysis tools. If you decide to explore that possibility, let us know what you come up with.
