Re: How to read an understand the bison report file ?

[Hans Aberg]

On 27 Jun 2012, at 13:18, Timothy Madden wrote:

>>> I wrote a grammar file for an approximation of the php language (with the 
>>> purpose of adding braces to single-statements under if, for, while, but 
>>> that is not included yet), that simply outputs the found tokens back to an 
>>> output stream.
>> 
>> If you want to write a grammar for a known language, there is a good chance 
>> somebody already has done so. You might inquiry in the Usenet newsgroup 
>> comp.compilers.
>> 
>>> My problem is I got like 233 shift/reduce conflicts (and 18 reduce/reduce 
>>> conflicts) and I do not really understand them. But searching the internet 
>>> shows most people have like 3 or 4 of them ... what did I do ?
>>> 
>>> Is there a way for me to understand that report file bison outputs ? I 
>>> looked a lot through it, but I can not get where the conflicts are comming 
>>> from. It does says something about the first rules, describing whitespace, 
>>> which I want to preserve as significant part of the grammar.
>>> 
>>> I have CenOS 6.2 64-bit (up-to-date), GNU bison 2.4.1 64-bit.
>>> The grammar and report files are attached.
>> 
>> Bison token preferences act on the tokens immediately before and after the 
>> parsing position '.' of the conflicting shift/reduce rules. So you might try 
>> to get rid some of them that way, by setting token precedences.
>> 
>> Reduce/reduce conflicts may call for the grammar to be rewritten - write a 
>> grammar for a more general language without them, and cut it down in the 
>> semantic actions. Or you may try to use the GLR parser - see the manual for 
>> an example, from parsing C++ I recall. It is possible to use the first 
>> method for that too, so it is part a matter of taste which method to choose.
> 
> I read the grammar file from the php sources. My problem is I want to 
> _preserve_ spaces. I only want to do add redundant braces around 
> single-statements under if/for/while. And completely dropping spaces and 
> comments from source code for such an operation is inappropriate. Not to 
> mention the real language is more complex than my approximation, and I am not 
> sure I can just copy the parser from another project..

Programming language specs often do not write grammars in any formal sense, but 
only give some rules that should be combined with other descriptions. Making a 
formal grammar can be very hard, for such reasons, and so it may be better to 
check if somebody already has done it, or can give advice for that particular 
language.

> After struggling with it for a day or more, I also began thinking my grammar, 
> with explicit spaces, is not really a one-token-only lookahead. I tried using 
> %glr-parser with no change in output.
> 
> Can bison really support GLR parsers with the C++ interface ?

I do not know; Paul is working on it (cc-ed).

> Because the documentation says I should use '%skeleton "lalr.cc"', which to 
> me suggests it is LALR only. I tried %skeleton "glr.cc", but then I got an 
> error that my YYSTYPE (which I defined to std::string) is not a legal member 
> for a union.
> 
> I know 2.4.1 is not latest, but it is the latest version on my Linux 
> distribution, CentOS, here at work.

Download latest, as no older version is supported, and make sure you have a 
fairly recent M4 installed, as Bison is using that to write the parser files 
from the skeleton file.

Hans