Re: Not getting parse error

[Rich Yonts]

Hans,

I'm very sorry that I did not supply what you asked for.  I didn't want to
make your analysis more difficult.  I simply didn't know what you wanted,
which is my problem not yours.  You obviously are very knowledgable about
this, but I'm very much an amateur.

However, your suggestion fixed my problem:

>Also note that as the Bison generated parser reduces to the right, it is
>better to write
>FieldList:
>     FieldList ',' FIELD {}
>     | FIELD {}
>as the parse stack then does not built up. See the Bison manual for more
>about this.

This change causes the failure to show up as I would expect.  Again, the
failure is expected when my pseudo-SQL does not conform to the
specification.  My reference to an error has nothing to do with Bison or
how it works.  I'm very pleased with Bison and it is a wonderful tool.

Please accept my apology for not being clear, please continue to offer help
to the less experienced, and know that I am grateful to you and Akim for
helping me.

Thanks,

Rich Yonts
address@hidden


To: Bison Help <address@hidden>
cc: Rich Yonts/Tucson/address@hidden
From: Hans Aberg <address@hidden>
Subject: Re: Not getting parse error



At 10:53 -0700 2002/02/04, Rich Yonts wrote:
>I was expecting that the invalid token (.) would cause an error since it
>doesn't fit in with my grammar at all.
...
>Let me give you the whole grammar:
>
>%token AND CONDITIONALOP FIELD LITERAL NOT OR
>
>%left OR
>%left AND
>
>%%
>
>Query :
>    Conditional ',' FieldList {
>          return(0);
>      } |
>    FieldList {
>          return(0);
>      }

You wrote before:
>Reading a token: Next token is 259 (FIELD)
>Shifting token 259 (FIELD), Entering state 22
>Reducing via rule 9 (line 44), FieldList ',' FIELD
>state stack now 0
>Entering state 6
>Reading a token: Next token is 46 ($undefined.)
>Reducing via rule 2 (line 26), FieldList  -> Query
and both I and Akim asked to see the rest.

-- It helps if you supply the things asked for. But:

As I said, LALR(1) may apply some additional reductions, but no more
shifts, before an error is issued. There is always one token to shift, the
implicit endmarker called "$" in yytname[] in the .tab.c file, unless one
aborts the parser.

Now, the "return 0" you have is the same as "abort with a success value".
So mu guess is that when the Bison generated parser reduces the rule Query
-> FieldList it aborts, exactly as you have written. -- If you would have
submitted the information requested, one would have been able to verify
this, but now you should be able to do it yourself.

Change the grammar to
Query:
    Conditional ',' FieldList {}
    | FieldList {}
...
to see if it helps.

>FieldList :
>    FIELD ',' FieldList {} |
>    FIELD {}

Also note that as the Bison generated parser reduces to the right, it is
better to write
FieldList:
    FieldList ',' FIELD {}
    | FIELD {}
as the parse stack then does not built up. See the Bison manual for more
about this.

  Hans Aberg