> > You *really* don't want to go there. If you want to see what the parser
> > is doing you can run "bison -r all" over the grammar and examine the
> > .output file. But please, let's not examine the internal states. Talk
> > about unmaintainability!
> What I was suggesting was that we might be able to extract the "follow
> set" from bison's tables, ie, the set of grammar symbols that are legal
> next inputs given the current parse state stack.

> I surely agree that we don't want code that goes like "if state is N
> then print message X" ... but the follow set should be stable

These are 2 different issues.

(1) computing the set of expected following tokens.

It is possible to do that, with some processing of bison tables.

(2) give advices based on guesses:
    for what I have looked so far, it could look like:

 - I'm here for rule "user_list", the previous token was ','
   OR I'm here for "select_expressions_list", last token was ',' and
      current token is "FROM"

   => "HINT: remove previous comma"

I don't think that (2) would be a bad idea, especially for my students.
The good point is that the cost would only be paid at error time.

> One way of describing Fabien's existing patch is that it's essentially
> keeping track of the follow set by hand :-(

Yes. I give name to existing states, and states leads to expected
follow tokens.

> > Also, I suspect that bison does a good bit of
> > optimisation by way of combining states that removes some of the
> > information you might need, but I haven't looked into it closely.
> That could be a showstopper if true, but it's all speculation at this
> point.

I think the information is there.

Fabien Coelho - [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to