Re: recursive rule not used

[James K. Lowden]

On Wed, 19 Oct 2022 10:13:12 -0400
"James K. Lowden" <jklowden@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