On Wed, 19 Oct 2022 10:13:12 -0400 "James K. Lowden" <jklow...@schemamania.org> wrote:
The problem is solved, but I don't understand why. > Further study of the report shows identical terms use different > states: > > 794 search_linear: SEARCH search_1_body ? search_1_cases > 795 | SEARCH search_1_body ? at END statements > search_1_cases The grammar file gave Bison too much freedom. It had this rule: search_linear: SEARCH search_1_body search_1_cases | SEARCH search_1_body at END statements search_1_cases That allowed Bison to create different states for two paths en route to search_1_cases. The working grammar forces (I think "forces"?) the generator to resolve everything before it comes to search_1_cases: search_linear: SEARCH search_1_place search_1_cases ; search_1_place: search_1_body | search_1_body at END statements ; Now, just a single state approaches search_1_cases. State 588 794 search_linear: SEARCH search_1_place ? search_1_cases WHEN shift, and go to state 920 Yay. If I'm learning the right lesson, it's to be wary of rules that share a final RHS nonterminal, especially if that nonterminal is complex. By introducing an intermediate reduction, you ensure only one possible state when that nonterminal is reduced. I do not see why this change should be necessary. That is why I suspect a bug. >From my point of view, the two versions are interchangeable. They might produce different parsers, but those parsers should accept the same language. I don't see how to offer a minimal example, either. In a minimal example, Bison would surely produce compatible parsers. Only under the weight of a 5400-line grammar with 1220 rules are such problems manifested. I'm happy to help explore this further if my understanding is correct. --jkl