30 Jan
2016
30 Jan
'16
11:52 p.m.
---
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
31 Jan
31 Jan
7:08 a.m.
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
<Nicolas.Anquetil(a)inria.fr> 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
Moose-dev(a)list.inf.unibe.ch
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."
11:44 a.m.
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
--
Nicolas Anquetil
RMod team -- Inria Lille
On Jan 30, 2016, at 11:52 PM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr> 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
Moose-dev(a)list.inf.unibe.ch
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
12:01 p.m.
Le 31/01/2016 11:44, Nicolas Anquetil a écrit :
On 31/01/2016 07:07, Tudor Girba wrote:
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.
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
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
3:21 p.m.
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:
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.
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
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 
5:15 p.m.
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
5:44 p.m.
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 :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
On 31/01/2016 07:07, Tudor Girba wrote:
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.
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
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
5:50 p.m.
Le 31/01/2016 17:14, Stephan Eggermont a écrit :
And you certainly found the key resource.
Thierry
On 31-01-16 15:21, stepharo wrote:
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
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
6:51 p.m.
On 31/01/2016 17:44, Thierry Goubier wrote:
Le 31/01/2016 15:21, stepharo a écrit :
I would love to use Smacc, but I don't feel like restarting from scratch
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
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
--
Nicolas Anquetil
RMod team -- Inria Lille
Le 31/1/16 12:01, Thierry Goubier a écrit :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Le 31/01/2016 11:44, Nicolas Anquetil a écrit :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
6:55 p.m.
Le 31/01/2016 18:51, Nicolas Anquetil a écrit :
On 31/01/2016 17:44, Thierry Goubier wrote:
Agreed :)
Le 31/01/2016 15:21, stepharo a écrit :
I would love to use Smacc, but I don't feel like restarting from scratch
right now. 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).
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 :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
9:06 p.m.
Le 31/1/16 17:44, Thierry Goubier a écrit :
Le 31/01/2016 15:21, stepharo a écrit :
Where? because I spent a couple of hours I only found SQL92
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.
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 :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Le 31/01/2016 11:44, Nicolas Anquetil a écrit :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
9:36 p.m.
Le 31/01/2016 21:06, stepharo a écrit :
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
Le 31/1/16 17:44, Thierry Goubier a écrit :
http://savage.net.au/SQL/
SQL-92, -99, -2003
Le 31/01/2016 15:21, stepharo a écrit :
Where? because I spent a couple of hours I only found SQL92 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.
But as I said we do not have it.
9:44 p.m.
Le 31/01/2016 21:08, stepharo a écrit :
Where Stephan found it?
https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y
But given that you have the LALR postgres grammar
in the source code
of postgres?
Where? 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
1 Feb
1 Feb
8:09 a.m.
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. 
4:29 p.m.
Le 1 févr. 2016 à 08:09, stepharo
<stepharo(a)free.fr> a écrit :
Excellent!
Thanks I will archive that.
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
Where? because I spent a couple of hours I only found SQL92
http://savage.net.au/SQL/ <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.
4:32 p.m.
2016-02-01 16:29 GMT+01:00 Anne Etien <anne.etien(a)univ-lille1.fr>fr>:
Le 1 févr. 2016 à 08:09, stepharo <stepharo(a)free.fr> a écrit :
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.
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.
First one, just a search on SELECT in the web page:
<query specification> <http://savage.net.au/SQL/sql-92.bnf.html#xref-query
specification> ::=
SELECT <http://savage.net.au/SQL/sql-92.bnf.html#xref-SELECT>[ <set
quantifier> <http://savage.net.au/SQL/sql-92.bnf.html#set quantifier> ]
<select
list> <http://savage.net.au/SQL/sql-92.bnf.html#select list> <table
expression> <http://savage.net.au/SQL/sql-92.bnf.html#table expression>
Thierry
Anne
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
4:35 p.m.
2016-02-01 16:32 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>om>:
2016-02-01 16:29 GMT+01:00 Anne Etien <anne.etien(a)univ-lille1.fr>fr>:
Cool, this hyperlinked grammar, by the way ;)
I wish all were like that...
Thierry
Le 1 févr. 2016 à 08:09, stepharo <stepharo(a)free.fr> a écrit :
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.
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.
First one, just a search on SELECT in the web page:
<query specification>
<http://savage.net.au/SQL/sql-92.bnf.html#xref-query%20specification>
::=
SELECT <http://savage.net.au/SQL/sql-92.bnf.html#xref-SELECT>[ <set
quantifier> <http://savage.net.au/SQL/sql-92.bnf.html#set%20quantifier> ]
<select
list> <http://savage.net.au/SQL/sql-92.bnf.html#select%20list> <table
expression> <http://savage.net.au/SQL/sql-92.bnf.html#table%20expression>
Thierry
Anne
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
4:37 p.m.
Le 1 févr. 2016 à 16:32, Thierry Goubier
<thierry.goubier(a)gmail.com> a écrit :
2016-02-01 16:29 GMT+01:00 Anne Etien <anne.etien(a)univ-lille1.fr
<mailto:anne.etien@univ-lille1.fr>>:
I clicked directly on the 2003 grammar.
Sorry.
Anne
Le 1 févr. 2016 à 08:09, stepharo
<stepharo(a)free.fr <mailto:stepharo@free.fr>> a écrit :
Excellent!
Thanks I will archive that.
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.
Where? because I spent a couple of hours I only found SQL92
http://savage.net.au/SQL/ <http://savage.net.au/SQL/>
SQL-92, -99, -2003
First one, just a search on SELECT in the web page:
<query specification> <http://savage.net.au/SQL/sql-92.bnf.html#xref-query
specification> ::=
SELECT <http://savage.net.au/SQL/sql-92.bnf.html#xref-SELECT>[ <set
quantifier> <http://savage.net.au/SQL/sql-92.bnf.html#set quantifier> ]
<select list> <http://savage.net.au/SQL/sql-92.bnf.html#select list> <table
expression> <http://savage.net.au/SQL/sql-92.bnf.html#table expression>
Thierry
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
> 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
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
26 Feb
26 Feb
10:54 p.m.
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 <thierry.goubier(a)gmail.com> a écrit :
Le 31/01/2016 21:08, stepharo a écrit :
Where Stephan found it?
https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y
But given that you have the LALR postgres grammar
in the source code
of postgres?
Where? 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
27 Feb
27 Feb
8:27 a.m.
https://github.com/postgres/postgres/blob/master/src/pl/plpgsql/src/pl_gram…
Verstuurd vanaf mijn iPad
Op 26 feb. 2016 om 22:54 heeft Anne Etien
<anne.etien(a)univ-lille1.fr> het volgende geschreven:
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
<thierry.goubier(a)gmail.com> a écrit :
Le 31/01/2016 21:08, stepharo a écrit :
Where Stephan found it?
https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev But given that you have the LALR postgres grammar
in the source code
of postgres?
Where? 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
8:58 a.m.
Thanks
Anne
Le 27 févr. 2016 à 08:27, Stephan Eggermont
<stephan(a)stack.nl> a écrit :
https://github.com/postgres/postgres/blob/master/src/pl/plpgsql/src/pl_gram…
Verstuurd vanaf mijn iPad
Op 26 feb. 2016 om 22:54 heeft Anne Etien
<anne.etien(a)univ-lille1.fr> het volgende geschreven:
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Le 31 janv. 2016 à 21:44, Thierry Goubier
<thierry.goubier(a)gmail.com> a écrit :
Le 31/01/2016 21:08, stepharo a écrit :
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
> 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
2980
days inactive
3008
days old
21 comments
6 participants
participants (6)
-
Anne Etien -
Nicolas Anquetil -
Stephan Eggermont -
stepharo -
Thierry Goubier -
Tudor Girba