Mark Butler <butlerm@middle.net> writes:
> Bruce Momjian wrote:
>
> > Interesting. What advantages would there be?
>
> As any one who has ever attempted to build a C++ parser using Yacc or Bison
> can attest, it is very difficult to get an LALR based parser to correctly
> parse a sophisticated grammar. The advantages of using a hand written
> recursive descent parser lie in four areas:
>
> 1) ease of implementing grammar changes
> 2) ease of debugging
> 3) ability to handle unusual cases
> 4) ability to support context sensitive grammars
>
> Context sensitivity is useful for handling things like embedded programming
> languages without having to escape whole procedures as string literals, for
> example. We could support procedural language plugins without the current
> limitations on syntax.
>
> Another nice capability is the ability to enable and disable grammar rules at
> run time - you could add run time options to disable all non SQL-92 grammar
> rules for application portability testing or emulate Oracle's outer join
> syntax, as a couple of examples.
On the other hand, recursive descent parsers tend to be more ad hoc,
they tend to be harder to maintain, and they tend to be less
efficient.
I believe that yacc based parsers support context sensitivity just as
well as recursive descent parsers.
I'm not sure that C++ is a fair example. The problem with parsing C++
is the result of a convoluted declaration syntax, so much so that some
constructs are completely syntactically ambiguous no matter how you
look at them and must be decided by semantic rules. It's true that in
such a case recursive descent is easier, because it is easier to mix
semantic rules and syntax rules. But the SQL syntax is much simpler;
is this really a problem with SQL? And I note that despite the
difficulties, the g++ parser is yacc based.
Ian
---------------------------(end of broadcast)---------------------------
TIP 462: A mushroom cloud has no silver lining.
