|SQL grammar problem with Visual Parse++ email@example.com (John) (2001-07-23)|
|Oracle grammar ambiguities and conflicts firstname.lastname@example.org (matt blackmon) (2006-01-09)|
|Re: Oracle grammar ambiguities and conflicts email@example.com (Josef Grosch) (2006-01-12)|
|Re: Oracle grammar ambiguities and conflicts firstname.lastname@example.org (Derek M. Jones) (2006-01-12)|
|Re: Oracle grammar ambiguities and conflicts cfc@shell01.TheWorld.com (Chris F Clark) (2006-01-12)|
|Re: Oracle grammar ambiguities and conflicts DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-01-12)|
|Re: Oracle grammar ambiguities and conflicts email@example.com (Evangelos Drikos) (2006-01-12)|
|Oracle grammar ambiguities and conflicts firstname.lastname@example.org (Mark Thiehatten) (2006-01-12)|
|[6 later articles]|
|From:||"matt blackmon" <email@example.com>|
|Date:||9 Jan 2006 23:54:39 -0500|
>I am attempting to write a parser for Oracle 7.3.4 SQL/PLSQL using
>Visual Parse++ 4.0. I have run into a problem where non-reserved
>keywords must be included as identifiers, causing millions of conflicts
>in the grammar. Does anyone have experience with either using VP++
>or with writing grammars for SQL?
>[That's a famous problem. There's a variety of less than fabulous
>solutions, hacks in the lexer to guess when to return a keyword and
>when to return a symbol, parser backup if it gags on a keyword, or
>bushy parsers that put all of the allowed keywords into the grammar
>in places where they can be used as symbols. -John]
Sorry for resurrecting an old post from 2001, but I am wrestling with
this same famous problem and have had no luck (beyond the original
post) finding help on this famous problem. I'm currently working on
an oracle 10g sql parser using flex/bison. Of the three solutions
mentioned by the moderator (are there more?), here are the stumbling
blocks I've encountered:
1) "parser backup if it gags on a keyword" -- not feasible in
bison/flex (to my knowledge), and most tools capable of producing backups
use exception based processing, which results in unacceptable performance
for my task.
2) "hacks in the lexer" -- trying this currently, but I find the regex
I use matching too much, or not catching enough. Additionally, trying lexer
"states" seems to replicate all the work in the parser for determining the
context for determining whether the word is a keyword or symbol. Should I
have the parser switch the state of the lexer depending on which rule it is
pursuing? This seems messy, causing some instances where I'd have to back
up the lexer and re-lex.
3) "bushy parsers that put all of the allowed keywords into the
grammar in places where they can be used as symbols" -- I'm currently doing
this in my parser (I think), but it leads to some ambiguities in some cases,
particularly with words like DEFAULT.
Lastly, would a LL grammar be more befitting this problem than a LR?
Any feedback or pointers you could give me would be greatly appreciated as
my searching of this group, other groups, and the internet as a whole has
mattblackmon AT NOhotmailJUNK.com
Return to the
Search the comp.compilers archives again.