Re: hint infrastructure setup (v3)
От | Andrew Dunstan |
---|---|
Тема | Re: hint infrastructure setup (v3) |
Дата | |
Msg-id | 406D8FE6.3050706@dunslane.net обсуждение исходный текст |
Ответ на | Re: hint infrastructure setup (v3) (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: hint infrastructure setup (v3)
|
Список | pgsql-patches |
Fabien COELHO wrote: >>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. > > 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! 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. If we really wanted to go down this route, a predictive (i.e. LL(n) type) parser rather than a bottom up parser would probably be more suitable, but I doubt anyone has any stomach for doing that work, even if there was agreement on the need for it. cheers andrew
В списке pgsql-patches по дате отправления: