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

[Timothy Madden]

On 06/28/2012 04:55 PM, Akim Demaille wrote:
> Le 28 juin 2012 à 14:51, Timothy Madden a écrit :
>
> > On 06/28/2012 10:09 AM, Akim Demaille wrote:
> > > > >   On the other hand, I could not get GLR with C++ yet…
> > > I have it working, but it's based on horrible hacks.  And
> > > I really mean horrible.  If PHP in itself does not need it,
> > > I would avoid it.
> >
> > That is what I was afraid of.
>
> So why don't you give a try to what I proposed?
>
> > I see the real php parser (from php source code) does not have a %glr 
> > directive, but it does have %expect 3, and I know php has the dangling 
> > elseif/else problem. Can a language with this issue be written in a LALR(1) 
> > grammar ?
>
> Yes, it can, which is obviously the case of php.  I
> suspect your question is rather "can this conflict be
> explicitly solved instead of relying on the shift
> precedence in s/r conflicts".  Yes again, give a higher
> precedence to the else token than the if-then rule.
> Or declare "%right if else".

I would try to include my spaces in the lexer tokens, and I have updated 
the lexer input for that, but I have some things I should understand 
first, like how does that help the grammar ?

My token type is always std::string, no need for that union. I am eager 
to see the new variant-based token type you guys are working on, I think 
that will really make the C interface "obsolete". :) Can you also 
include some common members, not only alternative members, in the 
variant ? Sometimes I want to have a member that selects the token type, 
and then a union where I select a member from, basted on the previous 
token type, like

struct token
{
    enum TokenType { int, string }
        token_type;

    variant
    {
        int intToken;
        str strToken;
    }
};

Back to my grammer file, I think I should still read some more 
documentation pages about precedence, as I kinda hoped to avoid that 
with more grammar rules, that would make precedence unnecessary for 
expressions.

Sorry to say the bison documentation is kind of unpleasant to read. A 
significant number of the initial chapters never attempt to cover one 
single item or aspect of bison completely. So I am never confident on 
what little I have already learned from those chapters, until I get to 
the reference chapters.

But if a rule like

if (expr)
    stmt;
[elseif (expr)
    stmt; ]
[elseif (expr)
    stmt; ]
[else
    stmt; ]

can be made legal LALR(1), than I no longer understand what is wrong 
with the explicit spaces all over every one of my grammer rules.

What is wrong with:

primary_expr:
  var | literal | ( space expr space ) ;

multiplicative_expr:
    primary_expr
        |
    multiplicative_expr space op space primary_expr;

additive_expr:
    multiplicative_expr
        |
    additive_expr space additive_op space primary_expr;

if_branch:
   space if space ( space expr space ) space stmt;

else_branch:
   space else space stmt;

They say space in the above case will make the grammar ambiguous because 
that space can include an arbitrary number of tokens, not just one. But 
than the compound if statement can have an arbitrary number of elseif 
brances, which is again an arbitrary number of tokens, and now I hear 
that works.

With my entire grammar, attached previously, ignoring those hundreds of 
conflicts I get 'syntax error' on the first binary operator in my php 
input file ("=". "+", "*", T_INSTANCEOF, ...). The rules for those 
operators seem pretty clear to me in the grammar. Trying to get that 
diagram with the `dot` tool from graphwiz took over 48h without 
completion on an Inter Core 2 Duo, after which I stopped the process.

What can be wrong with my rules about binary operators, they look pretty 
clear to me ?

Thank you,
Timothy Madden