Re: hint infrastructure setup (v3)

Dear Tom,

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

Not really in terms of state. The state should basically be the same.
However yes in terms of "explicit" state that are given explicit names.
And definitely in terms of actions, as you say.

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

Hmmm. I'm so much below zero! So maybe I think I won't resubmit a
"infrastructure patch with some hints for some commands", as it seems
just a lose of time.

> The sample hints you show in another message still aren't impressing me
> much,

I don't mean them to be impressive! It is not an expert system or a seer
I'm planing. I just want them to be useful to my students!

> but in any case they look like they only depend on being able to
> see what grammar symbols can follow the current point.

Yes. That's basically where the parser is when it generates an error, it
is expecting something and cannot find it. I could do more, but with more
efforts.

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

Yes.

> I don't know whether bison's internal tables expose that set in any
> useful fashion, but it surely seems worth a look.

Having a look is something I can do;-)

I'm afraid it looks like "internal state 1232, 43425 and 42523", but there
may be some support enough in the generated code to get something more
interesting. It would require to be able to get textual meta informations
out of the state number, which is possible if bison/flex people did
something about it.

I can remembre something like that, somewhere deep in my memory...

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

These states exists anyway. Once the first keyword(s) are passed, there is
much less troubles as the SQL syntax is really verbose, so it is usually
hard to get lost. The only real problem I had passed the first symbol, for
the part I played with, is with SET [SESSION|LOCAL] SESSION AUTHORIZATION
which needed a real bit of refactoring.

Also, it is better to avoid some factorizations if the semantics
is different. For instance, user_list is used both for groups and users,
so I switched during my tests to a user_list and a group_list.

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

I noticed that great care has been taken to avoid any ambiguity.
I have no intention to change that.

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr