Re: Parser Cruft in gram.y

On Tue, Dec 18, 2012 at 10:33:12AM +0100, Dimitri Fontaine wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > And on the other hand, if you could get a clean split between the two
> > grammars, then regardless of exactly what the split was, it might seem
> > a win. But it seemed to me when I looked at this that you'd have to
> > duplicate a lot of stuff and the small parser still wouldn't end up
> > being very small, which I found hard to get excited about.
>
> I think the goal is not so much about getting a much smaller parser, but
> more about have a separate parser that you don't care about the "bloat"
> of, so that you can improve DDL without fearing about main parser
> performance regressions.

In addition to this, there could well be uses for a more modular
parser. For example, if it turns out to be possible to do our parser
in a way that is exportable and (can be converted to a type that)
looks forward, client code could do a lot of interesting (and provably
correct) things.

> If we come out with no regression and no gain on the main query parser,
> I say it still worth the separation effort. And anyway we only add
> things to the main parser (queries) when the standard saith we have to.
>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > I'm not sure what other tool might be better though. I looked through
> > http://en.wikipedia.org/wiki/Comparison_of_parser_generators#Deterministic_context-free_languages
> > but it seems our options are a bit limited if we want something
> > that produces C. It's not clear to me that any of the likely options
> > are as mature as bison, let alone likely to substantially outperform it.
> > (For instance, Hyacc sounded pretty promising until I got to the part
> > about it doesn't yet support %union or %type.) Still, I didn't spend
> > much time on this --- maybe somebody else would like to do a bit more
> > research.
>
> I did spend a very little time on it too, with a different search angle,
> and did find that "experimental" thing that might be worth looking at,
> or maybe not.
>
> http://en.wikipedia.org/wiki/Parsing_expression_grammar
> http://piumarta.com/software/peg/

More angles:

http://wwwiti.cs.uni-magdeburg.de/~rosenmue/publications/SKS+08.pdf

Might anyone here wish to investigate this, given some kind of
resources for the initial study?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate