gram.y=>preproc.y

Michael Meskes <meskes@postgresql.org> writes:

The attached version now is able to generate an ecpg parser without a single
change in gram.y.

Sweet.

Also included is a perl version of the script created by a2p
and fixed by me. Unfortunately a2p did not generate working code, so I guess
eventually we have to only work with the perl version. I guess a perl hacker
can beautify the script quite a bit.

We should probably standardize on the perl version, ugly or not, because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as long
as no one has to look at it ;-) ... but if someone wants to beautify the
perl script they're surely welcome to do so.

A few notes:

* before committing we need to see the proposed diffs to the Makefiles
and the Windows build scripts.

* As-is, the first few lines of parse.pl contain an unportable hardwired
assumption about where the perl executable is. I'd suggest removing
those lines and having the makefile call the script as

$(PERL) parse.pl ...

* Can we get a $PostgreSQL$ version identifier into each file that
will be added to CVS?

regards, tom lane

On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:

We should probably standardize on the perl version, ugly or not,
because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as
long
as no one has to look at it ;-) ... but if someone wants to beautify
the
perl script they're surely welcome to do so.

I'd be happy to, but I haven't really been following this thread. What
does it do, and how do I make sure it continues to work as I refactor
it?

I'm fine to wait until it's committed, too.

Best,

David

David E. Wheeler wrote:

On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:

We should probably standardize on the perl version, ugly or not, because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as long
as no one has to look at it ;-) ... but if someone wants to beautify the
perl script they're surely welcome to do so.

I'd be happy to, but I haven't really been following this thread. What
does it do, and how do I make sure it continues to work as I refactor it?

I'm fine to wait until it's committed, too.

I have had a quick look at it. The perl is more than ugly - it's
unmaintainable IMNSHO. It violates perl best practice in many ways, and
reflects the age of the a2p utility quite badly.

There is no guarantee that the script won't have to be looked at.
Rather, the reverse is our experience, so this is a real consideration.

I agree that a perl version is much more desirable, but it really
requires a hand translation from awk rather than a hacked a2p output.

David, how is your awk-fu? If it's any good then I'm happy to leave it
to you. Otherwise I will try to make a few hours somewhere to un-uglify
this.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

I have had a quick look at it. The perl is more than ugly - it's
unmaintainable IMNSHO. It violates perl best practice in many ways, and
reflects the age of the a2p utility quite badly.

There is no guarantee that the script won't have to be looked at.
Rather, the reverse is our experience, so this is a real consideration.

I agree that a perl version is much more desirable, but it really
requires a hand translation from awk rather than a hacked a2p output.

IMHO awk was the wrong language to begin with, so I'd vote for a fresh
implementation with re-thought data structures rather than just cleaning
up around the edges. However, I would like any reimplementation to
happen after we get this in, not before. As long as we are agreed that
a perl script is the appropriate tool, someone can go off in a corner
and reimplement without holding up anything else. And it's surely past
time that Michael stops having to sync ecpg with the main grammar by
hand.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I have had a quick look at it. The perl is more than ugly - it's
unmaintainable IMNSHO. It violates perl best practice in many ways, and
reflects the age of the a2p utility quite badly.

There is no guarantee that the script won't have to be looked at.
Rather, the reverse is our experience, so this is a real consideration.

I agree that a perl version is much more desirable, but it really
requires a hand translation from awk rather than a hacked a2p output.

IMHO awk was the wrong language to begin with, so I'd vote for a fresh
implementation with re-thought data structures rather than just cleaning
up around the edges.

That was what I was intending. The awk would just be a guide as to the
required logic.

However, I would like any reimplementation to
happen after we get this in, not before. As long as we are agreed that
a perl script is the appropriate tool, someone can go off in a corner
and reimplement without holding up anything else. And it's surely past
time that Michael stops having to sync ecpg with the main grammar by
hand.

Sure. No argument at all from me.

cheers

andrew

Tom Lane wrote:

Michael Meskes <meskes@postgresql.org> writes:

Also included is a perl version of the script created by a2p
and fixed by me. Unfortunately a2p did not generate working code, so I guess
eventually we have to only work with the perl version. I guess a perl hacker
can beautify the script quite a bit.

We should probably standardize on the perl version, ugly or not, because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as long
as no one has to look at it ;-) ... but if someone wants to beautify the
perl script they're surely welcome to do so.

+1.

A few notes:

* before committing we need to see the proposed diffs to the Makefiles
and the Windows build scripts.

It might be worthwhile to make it as a perl module, called from the
commandline in Unix and just included directly in the win32 build
scripts. But someone more perly can comment on if that's a prettier way
or not:-)

//Magnus

On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:

David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to un-
uglify this.

My Perl is excellent, but my awk is remedial. What part does awk play?

Best,

David

David E. Wheeler wrote:

On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:

David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to
un-uglify this.

My Perl is excellent, but my awk is remedial. What part does awk play?

I know about your perl ;-)

The original is in awk. It's the a2p translation to Perl that's horrid.

It's OK - I'll do it before long.

cheers

andrew

Andrew Dunstan wrote:

David E. Wheeler wrote:

On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:

David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to
un-uglify this.

My Perl is excellent, but my awk is remedial. What part does awk play?

I know about your perl ;-)

The original is in awk. It's the a2p translation to Perl that's horrid.

It's OK - I'll do it before long.

I know awk well and perl mediocre so I can help.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Mon, Nov 10, 2008 at 11:03:37AM -0500, Tom Lane wrote:

* before committing we need to see the proposed diffs to the Makefiles
and the Windows build scripts.

Sure. I just committed the generated preproc.y file to see how it goes through
the buildfarm. I prefer to see the file is okay everywhere, before automating
things.

* As-is, the first few lines of parse.pl contain an unportable hardwired
assumption about where the perl executable is. I'd suggest removing
...

Sure, this is just how a2p creates it.

* Can we get a $PostgreSQL$ version identifier into each file that
will be added to CVS?

Definitely.

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!

On Mon, Nov 10, 2008 at 09:38:58AM -0800, David E. Wheeler wrote:

I'd be happy to, but I haven't really been following this thread. What
does it do, and how do I make sure it continues to work as I refactor
it?

Just run parse.pl < pgsql/src/backend/parser/gram.y > preproc.y and compare the
result to pgsql/src/interfaces/ecpg/preproc/preproc.y. Both files should be
identical.

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!