Re: Simple parsing problem

Eric Fowler <eric.fowler@gmail.com> wrote:
> This should be easy practice for the experts ..
> I am writing a bison grammar to parse strings coming from various
> kinds of attached devices.
>
> One of the strings is of the form:
> $FOO,field1,field2, 0,a,1,b,3,c, ....<CRLF>
>
>
> where there are a variable number of paired fields of the form
> <number> COMMA <text> COMMA. The comma is always a delimiter here,
> the text contains no commas.
>
> This one was easy, I did it like this:
> FOO opt_token opt_token dse_data_set
> {mumble ...}
>
> dse_data_set:
> dse_data_pair dse_data_set
> | dse_data_pair
>


>
> dse_data_pair:
> opt_token opt_token
> {
> ...my code here ...
> }
> ;
>
> opt_token:
> COMMA_DELIM TOKEN
> {
> memcpy($$, $2, sizeof($$)/sizeof(*$$) - 1);
> }
> | COMMA_DELIM
> { *$$ = 0;}
> ;
>
> All well and good. Now I got this curveball - it is the same as the
> other one, but it has another opt_token field after the variable
> length list of pairs:
>
> $FOOBAR,field1,field2,0,a,1,b,
> 3,c....,field3<CRLF>
>
> [An opt_token is just a comma delimited field that might be empty, BTW. ]
>
> I am getting shift-reduce conflicts when I try to handle this like this:
> FOOBAR opt_token opt_token dse_data_set opt_token
>
> I can vaguely see why this is happening ... the parser can't tell the
> diff between opt_tokens that are in pairs or 'in the wild'. But I am
> not clear how to fix this.


Try:


dse_data_set:
  dse_data_set dse_data_pair
  | dse_data_pair


Your definition forces parser to decide if dse_data_set is
complete too early. The deinition above allow extending
dse_data_set if it is followed by two tokens.


--
                                                            Waldek Hebisch
hebisch@math.uni.wroc.pl

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