On 31/01/2016 17:44, Thierry Goubier wrote:
Le 31/01/2016 15:21, stepharo a écrit :
> The main problem is that there is no PS/SQL BNF available.
> I found a SQL92 but nothing else.
> I found a lexer in antlr but nothing else.
Just searching five minutes I found many resources and a lot of
questions about LALR parsing of SQL (3 EBNF for recent SQLs, etc...).
But the point wasn't that; what a LALR/LR parser gives you is a
grammar ambiguity and conflicts... PetitParser will happily take your
grammar ans you will only discover when parsing something that it
doesn't do what you would like.
(The reference citation of Aho and Ullman is ... it may be difficult
to determine what the language is).
So since you have a grammar, use LALR to check it.
(I'm sure that LALR parsing of SQL is a solved problem. Maybe the info
is a bit hard to get, but this is all).
I would love to use Smacc, but I don't feel like restarting from scratch
we want to parse also postgres functions and since this is not part of
standard SQL the LALR grammar will not help with that part :-(
For info, I made progress on the grammar, by refactoring part of it and
delegating some parsing to "extension parsers" (see
PetitParserExtension-Core by Guilaume)
So I still don't know what happened, but at least I removed the problem :-)
> Le 31/1/16 12:01, Thierry Goubier a écrit :
>> Le 31/01/2016 11:44, Nicolas Anquetil a écrit :
>>> On 31/01/2016 07:07, Tudor Girba wrote:
>>>> Would it be possible to provide an isolated case so that we can debug
>>> the isolated test case is in the mail
>>> for the grammar, I am afraid this will be difficult.
>>> It is not my grammar but the postgres sql one that Anne and Olivier
>>> It is their first grammar and despite their best efforts, it shows
>>> (without blaming anyone, we all know how difficult it can be to
>>> create a
>>> full-fledged grammar, and frankly full postgres is proving far more
>>> complex that I would have ever thought)
>> Most languages have quirks in the grammar which makes it difficult.
>> Unexpectedly, LR/LALR type approaches may help because they point out
>> inconsistencies at the grammar compilation stage.
>>> I am trying to rationalise and simplify their grammar to understand
>>> these problems
>> Probably the right approach.
>> A simple test I'd do is take parts of it and have a look to the
>> conflicts raised in SmaCC... The grammar syntax is so similar between
>> both that you can switch between the two technologies, and, anyway,
>> given it is a full-fledged grammar, in won't be any longuer in any of
>> the parser tech available.
>> Moose-dev mailing list
> Moose-dev mailing list
Moose-dev mailing list
RMod team -- Inria Lille