Re: Oracle grammar ambiguities and conflicts

Chris F Clark <cfc@shell01.TheWorld.com>
17 Jan 2006 21:39:00 -0500

          From comp.compilers

Related articles
[2 earlier articles]
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)
Re: Oracle grammar ambiguities and conflicts parsersinc@earthlink.net (SLK Parsers) (2006-01-20)
| List of all articles for this month |

From: Chris F Clark <cfc@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 17 Jan 2006 21:39:00 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 01-07-118 06-01-029 06-01-032
Keywords: SQL, parse

Dr. Josef Grosch wrote:
> We solve the problem of non-reserved keywords with a variant of
> "parser backup if it gags on a keyword". The handling of syntax errors
> can be configured in the parsers generated by the LALR parser generator
> 'lark'. We have done this using the following "hack in the parser":
>
> At a syntax error we check whether the current token is a keyword.
> If an identifier token would be acceptable at this location then
> we convert the keyword token into an identifier token and continue parsing.


That "hack" should be fully general and work for any tool that you can
make the appropriate patches to. Moreover, it will work even if you
change the grammar so that the legal set of keywords at different
places change. It is about as elegant and robust a solution as one
could find. In fact, it's so ideal a solution, it's hard to consider
it a hack.


If you can do it this way, I recommend you do.


I'm going to add it to my bag-of-tricks.


The only "downside" of this solution is that it is outside the grammar
and involves patching the tool, so if you switch parser generators
(and very few people ever do), you have to reinvent the "hack" for the
new parser generator. However, if you switch parser generators, you
are likely to have to redo portions of the grammar and auxillary code
just to the idiosyncarcies of the new tool, such that this effort will
be negligible. In other words, there is no downside to this technique.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------


Post a followup to this message

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