[antlr-interest] ISO SQL 2003 Grammar

[Jim Idle]

I have a complete T-SQL ANTLR parser and tree parser (I sell it) that has
no left recursion issues and is almost LL(1), it needs a slight increase
in -Xmx but otherwise it is fine and works perfectly well in Java. In fact
Ter uses it to test ANTLR and to examine the types of lookahead issues
ANTLR can encounter. So a Java based SQL parser is entirely possible.

Jim

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Douglas Godfrey
> Sent: Monday, October 10, 2011 9:16 PM
> To: Ivan Bludov; Antlr-Interest Antlr.Org
> Subject: Re: [antlr-interest] ISO SQL 2003 Grammar
>
> I generated a C parser and lexer. they both generate and compile
> successfully on my machine with 8GB heap allocated to Antlr. Any less
> and both Antlr and Antlrworks encounter numerous bugs due to unchecked
> memory allocation failures.
>
> Antlrworks needs 512MB to 1GB just to be able to edit the grammar.
> Antlr needs a minimum of 6GB to generate code for just a few rules with
> exponential lookahead. In my emails to the antlr-interest group I
> discuss how to refactor the grammar to reduce it's memory requirement.
>
> I havent had time to work on the SQL2003 grammar due to my day job
> writing the join engine to a database system.
>
> If you have the time to work on the SQL2003 grammar start unravelling
> the recursive dependancies at rule
> nonparenthesized_value_expression_primary.
> There is a set of about 30-40 rules with multiple recursion pathways
> such that any rule in the set can be reached from any other rule in the
> set.
> That is why the memory requirement is so large.
>
> I don't believe that it will ever be possible to get a working parser
> in Java. A C language parser on the other hand is quite possible.
>
> On 10/9/11 11:51 PM, "Ivan Bludov" <ivan.bludov at gmail.com> wrote:
>
> >So as I wrote I read your previous posts ( and file comments of
> cause).
> >So at first I was surprised enough that so much system resources was
> >needed. But as Terence wrote "With 3.3 I find that it terminates in
> 12s
> >on my box with 220M ram"
> >(http://www.antlr.org/pipermail/antlr-interest/2011-
> April/041439.html).
> >So I got the same result with antl 3.3. So build results depend on
> >antlr version (different results on different antlr version). So with
> >antl 3.4 the building process seems to fall into infinite loop and
> thus
> >system resources don't matter. So with 3.3 build result is successful
> >about few seconds, but the generated parser has some errors. The
> >critical problem - I think - is that the parser has duplicated
> >(identical) case in some switch statements. So I posted these
> thoughts.
> >
> >Douglas Godfrey, I appreciate your work on SQL2003 parser. But I
> >couldn't see the work result. Could you write your environment? Antlr
> >version? Have you already use your generated parser in some another
> >project? Because the generated parser has some another errors: "big
> >grammar" problem with 64kbyte class - but it is another problem.
> >
> >Ivan Bludov
>
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> email-address