Re: problem compiling bison with gcc 3.0.5

[Akim Demaille]

>>>>> "Hans" == Hans Aberg <address@hidden> writes:

Hans> 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).

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

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

Hans, I have no alternative: POSIX rulez.

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

I'll have a look, thanks.  But understand that patches are always the
preferred form of suggestions :)

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.

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

I kind of agree.  In a wonderful world where I would have all the
resources I need, plus 179h/day, plus the desire to spend my days on a
project instead of my girlfriend, that would be kewl.

It turns out none of these hold.