Anyone can explain this PParser behaviour?
Locked
12
12
Anyone can explain this PParser behaviour?
 
|
--- testWhatTheHeck self parse: 'true' rule: #condition. self parse: 'true)' rule: #condition. self parse: 'true' rule: #expression. self parse: 'true)' rule: #expression. --- First 3 tests pass, last one fails But the grammar says: --- condition ^ expression --- Can anyone propose an explanation? [Notes: Yes I checked that I am testing the right grammar Yes the 'true)' test is strange, but this is precisely what I am trying to debug (why does it pass for #condition ?) ] nicolas -- Nicolas Anquetil RMod team -- Inria Lille _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
Would it be possible to provide an isolated case so that we can debug this?
If that is not possible, did you try debugging with the PetitParser Debugger? Doru > On Jan 30, 2016, at 11:52 PM, Nicolas Anquetil <[hidden email]> wrote: > > > --- > testWhatTheHeck > self parse: 'true' rule: #condition. > self parse: 'true)' rule: #condition. > self parse: 'true' rule: #expression. > self parse: 'true)' rule: #expression. > --- > > First 3 tests pass, last one fails > > But the grammar says: > --- > condition > ^ expression > --- > > Can anyone propose an explanation? > > [Notes: > Yes I checked that I am testing the right grammar > Yes the 'true)' test is strange, but this is precisely what I am trying to debug (why does it pass for #condition ?) > ] > > nicolas > > -- > Nicolas Anquetil > RMod team -- Inria Lille > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
On 31/01/2016 07:07, Tudor Girba wrote: > Would it be possible to provide an isolated case so that we can debug this? 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 are creating. 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) I am trying to rationalise and simplify their grammar to understand these problems > If that is not possible, did you try debugging with the PetitParser Debugger? Yes, but it does not simplify enough the process of debugging petit parser rules in this case I got lost nicolas > > Doru > > >> On Jan 30, 2016, at 11:52 PM, Nicolas Anquetil <[hidden email]> wrote: >> >> >> --- >> testWhatTheHeck >> self parse: 'true' rule: #condition. >> self parse: 'true)' rule: #condition. >> self parse: 'true' rule: #expression. >> self parse: 'true)' rule: #expression. >> --- >> >> First 3 tests pass, last one fails >> >> But the grammar says: >> --- >> condition >> ^ expression >> --- >> >> Can anyone propose an explanation? >> >> [Notes: >> Yes I checked that I am testing the right grammar >> Yes the 'true)' test is strange, but this is precisely what I am trying to debug (why does it pass for #condition ?) >> ] >> >> nicolas >> >> -- >> Nicolas Anquetil >> RMod team -- Inria Lille >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > -- > www.tudorgirba.com > www.feenk.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- Nicolas Anquetil RMod team -- Inria Lille _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
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 >> this? > 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 are > creating. > 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. Thierry _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
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. 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 >>> this? >> 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 are >> creating. >> 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. > > Thierry > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
On 31-01-16 15:21, stepharo wrote:
> The main problem is that there is no PS/SQL BNF available. No BNF, but there are the bison rules: https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y > I found a SQL92 but nothing else. > I found a lexer in antlr but nothing else. Indeed, a common problem. The main RDBMS vendors agreed on the SQL 92 standard and then didn't implement it, to keep their customers locked in. At least for PostgreSQL we can take a look at the source... Stephan _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
In reply to this post by stepharo
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). Thierry > 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 >>>> this? >>> 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 are >>> creating. >>> 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. >> >> Thierry >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
In reply to this post by Stephan Eggermont-3
Le 31/01/2016 17:14, Stephan Eggermont a écrit :
> On 31-01-16 15:21, stepharo wrote: >> The main problem is that there is no PS/SQL BNF available. > > No BNF, but there are the bison rules: > > https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y Then this is the best case for a language parser. Proven LALR/GLR to start with. A working true grammar available. Maybe hacks inside the lexer. So there is no work to be done. Almost none. Take that bison grammar, understand a bit some of the bison quirks, reproduce and you're done. Thierry >> I found a SQL92 but nothing else. >> I found a lexer in antlr but nothing else. > > Indeed, a common problem. The main RDBMS vendors agreed on the SQL 92 > standard and then didn't implement it, to keep their customers locked > in. At least for PostgreSQL we can take a look at the source... And you certainly found the key resource. Thierry > Stephan > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
In reply to this post by Thierry Goubier
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). > right now. 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 :-) nicolas > Thierry > >> 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 >>>>> this? >>>> 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 >>>> are >>>> creating. >>>> 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. >>> >>> Thierry >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- Nicolas Anquetil RMod team -- Inria Lille _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
Le 31/01/2016 18:51, Nicolas Anquetil a écrit :
> > > 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 > right now. Agreed :) > 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 :-( But given that you have the LALR postgres grammar in the source code of postgres? > 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 :-) Which is good news :) Thierry > nicolas > >> Thierry >> >>> 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 >>>>>> this? >>>>> 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 >>>>> are >>>>> creating. >>>>> 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. >>>> >>>> Thierry >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by Thierry Goubier
Le 31/1/16 17:44, Thierry Goubier a écrit : > 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...). Where? because I spent a couple of hours I only found SQL92 > > 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. But as I said we do not have 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). > > Thierry > >> 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 >>>>> this? >>>> 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 >>>> are >>>> creating. >>>> 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. >>> >>> Thierry >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by Thierry Goubier
> But given that you have the LALR postgres grammar in the source code > of postgres? Where? Because I'm interested. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
In reply to this post by stepharo
Le 31/01/2016 21:06, stepharo a écrit :
> > > Le 31/1/16 17:44, Thierry Goubier a écrit : >> 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...). > > Where? because I spent a couple of hours I only found SQL92 http://savage.net.au/SQL/ SQL-92, -99, -2003 >> 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. > > But as I said we do not have it. You do have a PEG grammar in your PetitParser efforts, since you have been working on it. From far, those grammars are very much like other grammars... just that the parser generator behave differently when you have conflicts and ambiguity. Thierry _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
In reply to this post by stepharo
Le 31/01/2016 21:08, stepharo a écrit :
> >> But given that you have the LALR postgres grammar in the source code >> of postgres? > > Where? Where Stephan found it? https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y > Because I'm interested. I had a look. It's long (14000 lines) but there is a bit of noise in there (semantic actions and support functions). It's nice, well commented and the layout is very clear. Probably the nicest I've come accross. The other key to check is the lexer. One can hide a lot of complexity inside the lexer (R, I'm looking at you!). Thierry > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by Thierry Goubier
>> Where? because I spent a couple of hours I only found SQL92 > > http://savage.net.au/SQL/ > > SQL-92, -99, -2003 Excellent! Thanks I will archive that. > >>> 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. >> >> But as I said we do not have it. > > You do have a PEG grammar in your PetitParser efforts, since you have > been working on it. From far, those grammars are very much like other > grammars... just that the parser generator behave differently when you > have conflicts and ambiguity. > > Thierry > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
I am not an expert in grammar, but I don’t see on this page the rules relative to function or even to select query. Anne
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
2016-02-01 16:29 GMT+01:00 Anne Etien <[hidden email]>:
First one, just a search on SELECT in the web page: <a href="http://savage.net.au/SQL/sql-92.bnf.html#xref-query specification" name="query specification" style="font-family:'Times New Roman';font-size:medium"><query specification> ::= SELECT [ <a href="http://savage.net.au/SQL/sql-92.bnf.html#set quantifier" style="font-family:'Times New Roman';font-size:medium"><set quantifier> ] <a href="http://savage.net.au/SQL/sql-92.bnf.html#select list" style="font-family:'Times New Roman';font-size:medium"><select list> <a href="http://savage.net.au/SQL/sql-92.bnf.html#table expression" style="font-family:'Times New Roman';font-size:medium"><table expression> Thierry
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
2016-02-01 16:32 GMT+01:00 Thierry Goubier <[hidden email]>:
Cool, this hyperlinked grammar, by the way ;) I wish all were like that... Thierry
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
In reply to this post by Thierry Goubier
Sorry. Anne
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Anyone can explain this PParser behaviour?
|
|
In reply to this post by Thierry Goubier
We briefly have a look with Nicolas today and it seems that there is not the description of the function with begin, end.
But it is not so strange when we have a look at postgresql 9.5 specifications http://www.postgresql.org/docs/current/static/sql-createfunction.html (definition: A string constant defining the function; the meaning depends on the language. It can be an internal function name, the path to an object file, an SQL command, or text in a procedural language.) Hard to parse in that condition and we want to parse the content of the function. Any idea? Is there a pl/psql grammar? Anne Le 31 janv. 2016 à 21:44, Thierry Goubier <[hidden email]> a écrit : > Le 31/01/2016 21:08, stepharo a écrit : >> >>> But given that you have the LALR postgres grammar in the source code >>> of postgres? >> >> Where? > > Where Stephan found it? > > https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y > >> Because I'm interested. > > I had a look. It's long (14000 lines) but there is a bit of noise in there (semantic actions and support functions). > > It's nice, well commented and the layout is very clear. Probably the nicest I've come accross. > > The other key to check is the lexer. One can hide a lot of complexity inside the lexer (R, I'm looking at you!). > > Thierry > >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |