[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why this is shift/reduce?
From: |
Carl Cerecke |
Subject: |
Re: why this is shift/reduce? |
Date: |
Fri, 07 Feb 2003 13:52:13 +1300 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 |
Jibin Han wrote:
Hello,
Bison complains the following shift/reduce error at
chip_param_define section(the last part), I am confused here, could you
tell me why it is?
board:chips {}
chips: chip {}
|
chips chip {}
chip: BEGIN_FPGA chip_defines cores END {}
chip_defines: chip_param_define {}
|
chip_defines chip_param_define {}
chip_param_define: /* empty */
|
PARAMETER_INSTANCE CHIP_INSTANCE_NAME {}
|
DEVICE CHIP_DEVICE_NAME {}
The problem is the "chip_param_define -> /* empty */" rule
in combination with the fact that a chip_param_define
can follow another chip_param_define (from the definition
of chip_define)
The generated parser, when it sees, for example:
PARAMETER_INSTANCE CHIP_INSTANCE_NAME
could either shift PARAMETER_INSTANCE, or reduce
using the "chip_param_define -> /* empty */" rule,
and then shift PARAMETER_INSTANCE. In fact, you
could reduce "chip_param_define -> /* empty */"
an abitrary number of times before you decided to
shift.
Confused? Draw out the derivation tree twice on paper.
Once without using the "chip_param_define -> /* empty */"
rule, and once using it.
The solution I would recommend in this case is
to change the chip_defines rule to derive 0 or more
chip_param_defines (rather than 1 or more like it is
now), and change chip_param_define so it cannot
derive /* empty */.
Cheers,
Carl.