Re: Reduce/Reduce Conflict ?

Matt <matt@NOSPAMbeastrider.com>
24 Feb 2003 13:51:55 -0500

          From comp.compilers
Related articles
Reduce/Reduce Conflict ? ashwin21_99@hotmail.com (Ashwin) (2003-02-21)
Re: Reduce/Reduce Conflict ? matt@NOSPAMbeastrider.com (Matt) (2003-02-24)
Re: Reduce/Reduce Conflict ? snicol@apk.net (Scott Nicol) (2003-02-24)
Re: Reduce/Reduce Conflict ? slk14@earthlink.net (SLK Parsers) (2003-03-02)
| List of all articles for this month |
From: Matt <matt@NOSPAMbeastrider.com>
Newsgroups: comp.compilers
Date: 24 Feb 2003 13:51:55 -0500
Organization: AT&T Broadband
References: 03-02-124
Keywords: parse
Posted-Date: 24 Feb 2003 13:51:54 EST

Ashwin wrote:




> The Grammar is as follows:
>
> PrimaryExpression:
> ParenthesizedExpression
> | CastExpression
> ;
>
> ParenthesizedExpression:
> OPENPAREN Expression CLOSEPAREN
> ;
>
> CastExpression:
> OPENPAREN Type CLOSEPAREN IDENTIFIER
> ;
>
> Expression:
> IDENTIFIER
> ;
>
> Type:
> IDENTIFIER
> ;


Either use bison with %glr-parser or flatten parenthesizedexpression and
castexpressiion to be a single rule and manually decide if it's a cast
or not later on. Your resulting grammar will be a mess. This is the
great ugly with lalr(1) parsers.


Would it be possible to build a tool that would take a grammar like this
and rewrite the rules, or at least try and rewrite the rules, to remove
these kinds of problems?


Matt


Post a followup to this message

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