help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with shift/reduce conflict


From: Kelly Leahy
Subject: Re: Problem with shift/reduce conflict
Date: Thu, 6 Jan 2005 09:02:51 -0800 (PST)

I didn't look at all of your problems because my
german isn't very good and I was getting tired of
figuring out which error messages meant what.

However, I believe that at least one of your big
problems stems from a very common problem in C
grammars.  There is an inherent S/R conflict in most C
grammars with respect to the difference between
variable declarations and function declarators.  Both
of these can appear in the same places and they are of
the form:

INT ID ( ... )     (function declarator)
INT ID             (variable declarator)

the problem is that if the INT is coming from a
different nonterminal in each rule, then there is a
shift/reduce conflict in the nonterminals from which
it comes because they don't know whether to reduce or
shift.

This may not be the best explanation, as I'm not
trying very hard (sorry) but its a problem I've
encountered often, and most of the time, my solution
was to either consolidate the grammar a bit so that
there are less choices for where to shift/reduce (i.e.
split out some of the common stuff into
sub-nonterminals and use those in my rules, rather
than the more all incompassing nonterminal) or to
switch to a GLR parser and resolve the ambiguity by
allowing it to try a few things before it gives up.

Kelly

--- address@hidden wrote:

> Hi all,
> 
> I am currently working on a grammar for simple
> Integer C (only allows data
> type integer and therefore selected operations) but
> my grammar produces
> S/R conflictsI 
> 
> All conflicts appear when the non-terminal
> "Type_Specifier" is involved,
> so there must be something wrong there. I worked
> through it but can`t find
> any errors. 
> 
> Please find attached the .output file that is
> created when running bison,
> 
> the grammar is included. Any help would be highly
welcome...

> ATTACHMENT part 2 application/octet-stream
name=next_step_Conv_stmt.output
> _______________________________________________
> address@hidden
http://lists.gnu.org/mailman/listinfo/help-bison





reply via email to

[Prev in Thread] Current Thread [Next in Thread]