> > 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
