Re: problem compiling bison with gcc 3.0.5

[Hans Aberg]

At 13:33 +0100 2002/03/02, Akim Demaille wrote:
>>> BTW: if anyone likes to answer me some basic questions + Why can't
>>> I %expect reduce/reduce conflicts?
>
>Hans> If you only figure out an automated way to select which rule to
>Hans> reduce.  What do you prefer? (One can take say the longer rule,
>Hans> but what you do if the rules are of the same length?)
>
>The algorithm in such a case is simply reducing the first rule (in the
>order of appearance).

Sorry: I should have looked this up before replying. :-)

You might try using length first, then order, just as in Flex. -- Also, one
might check if it is possible to use precedence by computing LAST.

Note, however, that the parsing when the %expect is being used depends not
only on the grammar, but also on the algorithm used (LALR, LR etc). So
therefore, apart from the use as a tool in the construction phase of a
grammar, I am sceptic about its use: One should have grammar specific tools
available to remove ambiguities. (So, I think that the Bison manual section
5.2 is wrong on this point: it is better to specify a correct grammar using
%nonassoc.)

Bug Bison?: %expect seems to not be mentioned in the Bison 1.33 manual
Appendix A.

>>> * passing some objects to the yyparse() function
>
>Hans> Check YYPARSE_PARAM, Bison manual sec 4.2.4.
>
>We are looking for elegant means to add members, not just one.  But it
>is not clear whether it's easily feasible, nor desirable.

When I worked a bit on a pure Flex parser, it looked as though these two
features (Flex/Bison pure parser) might be needed to be tuned together: The
Bison pure parser will be calling the Flex pure parser repeatedly. So one
might want to put some of the Flex variables into the Bison pure yyparse()
function body.

  Hans Aberg