Thread: gram.y => preproc.y
I finally have a working version. Please have a look at the attached files including a changed version of gram.y and and automatically created version of preproc.y. To recreate just run "awk -f parse.awk < gram.y > preproc.y". Is it okay to change gram.y this way? It does run the regression suite successfully. I'd like to do some more tests on the ecpg side, but this version also runs the regression suite successfully, well sort of. There are quite a lot of cosmetic differences, mostly whitespaces and some different writings of commit/begin/..., but no functional difference any more. To test you need an up-to-date HEAD because ecpglib didn't like an additional blank. Comments/improvements/bug reports welcome. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> I finally have a working version. Please have a look at the attached files
> including a changed version of gram.y and and automatically created version of
> preproc.y. To recreate just run "awk -f parse.awk < gram.y > preproc.y".
Ping? I've been expecting a followup that actually has the attachments ...
(You might need to compress the files if the message comes to more than
100-some KB. Also, given that preproc.y can be generated so easily, it
could just be left out.)
regards, tom lane
On Mon, Nov 03, 2008 at 07:10:01PM -0500, Tom Lane wrote: > > preproc.y. To recreate just run "awk -f parse.awk < gram.y > preproc.y". > > Ping? I've been expecting a followup that actually has the attachments ... I send out a new version immediately on Sunday but apparently it never made it to the list. Strange. But then complains about email problems don't seem to make sense, they are not answered anyway. > (You might need to compress the files if the message comes to more than > 100-some KB. Also, given that preproc.y can be generated so easily, it > could just be left out.) I did this this time. The file is just 84K. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Attachment
Michael Meskes <meskes@postgresql.org> writes:
> On Mon, Nov 03, 2008 at 07:10:01PM -0500, Tom Lane wrote:
>> (You might need to compress the files if the message comes to more than
>> 100-some KB. Also, given that preproc.y can be generated so easily, it
>> could just be left out.)
> I did this this time. The file is just 84K.
Came through this time, thanks.
I'm quite unhappy with the invasiveness of the proposed gram.y changes.
The @ECPG annotations are bad enough, but why are you changing actual
productions? I'm not entirely convinced that the backend still parses
exactly what it did before.
It strikes me that most if not all of the @ECPGINCLUDE annotations ought
to be unnecessary given that you've carefully identified each chunk of
ecpg.addons. The substitution script ought to be able to match those
annotations to the input for itself.
FWIW, I'm also pretty firmly convinced that awk was the wrong choice for
implementing this script...
regards, tom lane
On Tue, Nov 04, 2008 at 01:03:44PM -0500, Tom Lane wrote: > I'm quite unhappy with the invasiveness of the proposed gram.y changes. Keep in mind that this is work in progress. I'm still working on this stuff and yes, I'm trying to simplify things. > The @ECPG annotations are bad enough, but why are you changing actual > productions? I'm not entirely convinced that the backend still parses > exactly what it did before. There are essantially two changes (unless I forgot about a third one :-)): - fetch_count: I can remove that one easily by including the block on every single production for fetch. Doesn't look like a problem. This change came from me taking some stuff from preproc.y to get a working version first before simplifying. - variable handling: This creates the most changes. ECPG needs to accept variables at quite some places where the backend only accepts constants. The easy way (again WIP) is to add a variable production to each constant rule. However, this obviously creates conflicts when allowinf Sconst and Iconst for the same non-terminal. Therefore I added new non-terminals SconstVar and IconstVar that just resolve to Sconst and Iconst in gram.y. If you have a better idea I'm willing to listen. > It strikes me that most if not all of the @ECPGINCLUDE annotations ought > to be unnecessary given that you've carefully identified each chunk of > ecpg.addons. The substitution script ought to be able to match those > annotations to the input for itself. You mean by hard coding the position? Hmm, that's possibly but creates just another situation where we might need a manual sync. Just take an addition that's supposed to be added to the second rule for a non-terminal. Now if you insert something before that second rule, it won't work anymore. > FWIW, I'm also pretty firmly convinced that awk was the wrong choice for > implementing this script... Well, I work with what I have. What language would you prefer? And btw what makes you so convinced? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!