Re: why this is shift/reduce?

[Aaron Gray]

> 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 */.

I would suggest that the problem may possibly be lexical as well. If the
input file is delimited with carrage returns then you may need to match
them.

Thought I better say just in case,

Aaron