Conflicts in large grammar

[Laurence Finston]

Hello,

I've run into a problem with the grammar of GNU 3DLDF.  It's rather large, 
and I believe that's part of the problem, so it's not 
possible to provide a minimal example.  I tried to attached the 
debugging output files from three runs of Bison in a tarball, 
but I kept getting my message returned.  I've now attached them as plain 
text files.

I would like to have the following rule:

point_primary: GET_POINT numeric_secondary conic_section_lattice_primary

When I run Bison, however, I get the following, not very informative
message:  Abort 

Bison succeeds when I change the rule, with varying numbers of conflicts:

point_primary: GET_POINT LEFT_PARENTHESIS numeric_secondary COMMA 
conic_section_lattice_expression RIGHT_PARENTHESIS

-->

parser.y++: conflicts: 421 shift/reduce, 1 reduce/reduce

There were 420 s/r conflicts before I added the rule.  I don't consider 
this to be a problem.

(See debugging output file `p0.txt' in attached tarball.)

*********************

point_primary: GET_PATH_POINT LEFT_PARENTHESIS numeric_secondary COMMA 
conic_section_lattice_expression RIGHT_PARENTHESIS

-->

parser.y++: conflicts: 424 shift/reduce, 1 reduce/reduce

(See `p1.txt' in attached tarball.)

*********************

point_primary: GET_POINT numeric_secondary COMMA 
conic_section_lattice_expression

parser.y++: conflicts: 844 shift/reduce, 1 reduce/reduce

(See `p2.txt' in attached tarball.)

************************

The relationship between the states and the rules seems to be rather
complex.  When Bison has failed before, I've sometimes been able to
fix the problem by using a `<type>_secondary' or `<type>_tertiary' 
rather than a `<type>_primary' or making a similar substition.  
This didn't work in this case.

I also tried using a different token instead of `GET_POINT', namely
`GET_PATH_POINT'.  The results were similar, but not completely 
the same.  I really don't want to be using parentheses or 
different tokens like this if I can avoid it.

My grammar is likely to become larger and more complex as I add symbols 
and and rules for more geometrical entities, so I'm afraid this will 
keep happening.  

Any suggestions would be much appreciated.

Laurence Finston

p0.txt
Description: Text document

p1.txt
Description: Text document

p2.txt
Description: Text document