Parser ambiguity
Sun, 15 Mar 2009 10:53:23 -0700 (PDT)

          From comp.compilers

Related articles
Parser ambiguity (2009-03-15)
Re: Parser ambiguity (Chris F Clark) (2009-03-15)
Re: Parser ambiguity (Max Hailperin) (2009-03-15)
Re: Parser ambiguity (2009-03-16)
Re: Parser ambiguity (2009-03-16)
| List of all articles for this month |

Newsgroups: comp.compilers
Date: Sun, 15 Mar 2009 10:53:23 -0700 (PDT)
Organization: Compilers Central
Keywords: parse, GLR, question
Posted-Date: 15 Mar 2009 16:59:24 EDT

I'm trying to solve this ambiguity in my Bison GLR parser. I would
appreciate any insights. The relevant rules are these:

    statement_sequence statement |
    statement ;

    type variable_declaration_list ';' |
    '{' statement_sequence '}' |
    function_declaration |
    ...more statements... ;

    type identifier '(' formal_parameter_list
')' |
    type identifier '(' formal_parameter_list ')' '{' statement_sequence
'}' |
    function_declaration "body" '{' statement_sequence
'}' |
    function_declaration "pre" '{' statement_sequence
'}' |
    function_declaration "post" '{' statement_sequence
'}' ;

Nested function declarations, so function declarations are statements.

Each function must have a body, but may include a pre- and/or
postcondition. The three may have any order. If the body is first, the
"body" keyword may be skipped. I didn't want to put every possible
combination literally in the grammar. I'd check for missing/double
sections after parsing.

The problem is that, syntactically, a function-declaration doesn't
need any sections, and the following example (statement_sequence) is
ambiguous, because the grammar also allows local { } scopes:

int f()
    int i;

I don't believe there is a %dprec solution as the grammar stands (but
I may be wrong). I'd like to avoid code duplication as much as
possible, so I wouldn't like to literally sum up all possibilities for

Any thoughts on how to solve this problem?

Michiel Helvensteijn
[When you get the r/r conflicts, which rules are they? -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.