Fabien COELHO <[EMAIL PROTECTED]> writes:
> I would not like to break postgresql portability with other parser
> generators.
I agree with Bruce's opinion that this is a nonissue. In particular I'd
point out that the current grammar is already too big for any known yacc
clone besides bison (even with bison you need a very recent version),
and your proposed changes are going to make the grammar a whole lot
larger yet, at least in terms of states and actions. Even if there was
any usefulness to supporting other yacc clones, the odds of making one
work seem minuscule.
> Using some non standard undocumented API would not help other people who
> would like to touch the parser.
It would help them a *lot* if it meant that they didn't have to be aware
of this stuff in order to do anything at all with the grammar. My
fundamental objection to this proposal continues to be that it will make
the grammar unreadable and unmaintainable. If we could push the error
message generation issues into a subroutine of yyerror() and not touch
the grammar rules at all, the chances of getting this accepted would
rise about a thousand percent.
The sample hints you show in another message still aren't impressing me
much, but in any case they look like they only depend on being able to
see what grammar symbols can follow the current point. The last time
I studied this stuff (which was quite a while back) the follow set was
something an LR parser generator would have to compute anyway. I don't
know whether bison's internal tables expose that set in any useful
fashion, but it surely seems worth a look.
regards, tom lane
PS: another reason for doing it that way is that I suspect your current
approach is a dead end anyhow. You've already hit one blocker problem
where you got reduce/reduce errors when you tried to insert
state-recording actions, and you've only gone as far as hinting the very
first symbol, which is hardly one of the more complex parts of the
grammar. There are large parts of the grammar that only manage to avoid
ambiguity by the skin of their teeth --- I don't believe you'll be able
to do anything of this sort in those areas without breaking it. Take a
look at SelectStmt and subsidiary productions as an example ... that's
a fragile bit of work that took a long time to get right.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
