Re: Oracle grammar ambiguities and conflicts

"Evangelos Drikos" <drikosv@otenet.gr>
12 Jan 2006 12:13:09 -0500

          From comp.compilers

Related articles
SQL grammar problem with Visual Parse++ junk@junk.com (John) (2001-07-23)
Oracle grammar ambiguities and conflicts mattblackmon@hotmail.com (matt blackmon) (2006-01-09)
Re: Oracle grammar ambiguities and conflicts grosch@cocolab.de (Josef Grosch) (2006-01-12)
Re: Oracle grammar ambiguities and conflicts derek@knosof.co.uk (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 drikosv@otenet.gr (Evangelos Drikos) (2006-01-12)
Oracle grammar ambiguities and conflicts mark.thiehatten@bibit.com (Mark Thiehatten) (2006-01-12)
Re: Oracle grammar ambiguities and conflicts cfc@shell01.TheWorld.com (Chris F Clark) (2006-01-17)
Re: Oracle grammar ambiguities and conflicts mattblackmon@hotmail.com (Matt Blackmon) (2006-01-17)
Re: Oracle grammar ambiguities and conflicts david@tribble.com (David R Tribble) (2006-01-17)
Re: Oracle grammar ambiguities and conflicts parsersinc@earthlink.net (SLK Parsers) (2006-01-19)
Re: Oracle grammar ambiguities and conflicts parsersinc@earthlink.net (SLK Parsers) (2006-01-19)
[1 later articles]
| List of all articles for this month |

From: "Evangelos Drikos" <drikosv@otenet.gr>
Newsgroups: comp.compilers
Date: 12 Jan 2006 12:13:09 -0500
Organization: An OTEnet S.A. customer
References: 01-07-118 06-01-029
Keywords: parse, SQL

Hi all,
Hi Matt,


"matt blackmon" <mattblackmon@hotmail.com> wrote
>Of the three solutions
>mentioned by the moderator (are there more?), here are the stumbling
>blocks I've encountered:


My opinion is you combine solution 3 with a GLR and avoid headaches. I
think it will work. At least you will not have to deal with one million
conflicts.


I've worked a little with SQL-92, not Oracle Syntax, but I believe the
problem with the non-reserved words is common.


Also, I hope Oracle Syntax is less ambiguous than SQL-92, otherwise you
have to make excessive restatements, if you want to solve them at the
syntax level.


Anyway, let us see solution-3.


"matt blackmon" wrote
>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.


I will try to give you an idea what to check again.


I think, even in Oracle, 'DEFAULT' is a reserved word.


Further, 'Bison' is a LALR Parser, according to the description at
  http://www.gnu.org/software/bison/bison.html#introduction .


Thus, you possibly have encountered conflicts rather ambiguities due
to keywords.


What you could possibly try to deal with these problems?


Let us assume the rule that describes the Lexical Conventions of an
identifier that is not delimited is named "regular identifier", set:


(a) <regular identifier> ::= <_regular identifier>
                                                    | <non reserved word>


(b) <_regular identifier> ::=
        "here place the old definition of <regular identifier>"


(c) All reserved & non-reserved words should be placed in flex
before the definition of <_regular identifier>.


According to the Flex documentation, when input matches multiple
declarations, it gives priority to the rule stated first.


So, such a restatement might work.


After, I am not certain what conflicts you might face with
Oracle Syntax. One solution is, you let a GLR deal with conflicts
and you just have to deal with ambiguities, if any.




I hope this helps,


Ev. Drikos


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.