Re: Updatable views/with check option parsing

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
> As I understand it, it runs one parser pretty much like the standard LALR(1)
> case, until it finds an ambiguity (shift/reduce or reduce/reduce) at which
> stage it clones the parser to take parallel paths, working in lockstep, and
> storing up semantic actions. When one of the clones encounters an error it
> goes away, and the surviving clone takes its stored semantic actions. If
> that's true, then probably the only significant performance hit is in cases
> of ambiguity, and we would only have a handful of those, each lasting for
> one token, so the performance hit should be very small. We'd have to test
> it, of course ;-)

Yeah, I just read the same in the bison manual. The thing that's
bothering me is that a GLR parser would hide that ambiguity from you,
and thus changes in the grammar might cause us to incur performance
hits without realizing it. The manual indicates that the performance
is pretty awful whenever an ambiguity does occur.

regards, tom lane