Обсуждение: 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!

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!