Parser ambiguity

m.helvensteijn@gmail.com
Sun, 15 Mar 2009 10:53:23 -0700 (PDT)

          From comp.compilers

Related articles
Parser ambiguity m.helvensteijn@gmail.com (2009-03-15)
Re: Parser ambiguity cfc@shell01.TheWorld.com (Chris F Clark) (2009-03-15)
Re: Parser ambiguity max@gustavus.edu (Max Hailperin) (2009-03-15)
Re: Parser ambiguity m.helvensteijn@gmail.com (2009-03-16)
Re: Parser ambiguity m.helvensteijn@gmail.com (2009-03-16)
| List of all articles for this month |
From: m.helvensteijn@gmail.com
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_sequence statement |
    statement ;


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


function_declaration:
    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
function_declaration.


Any thoughts on how to solve this problem?


Thanks!
--
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.