Hi,

I recently (on my flight to Ottawa) changed ecpg to use the keyword list
of the backend instead of its own. This means that there is one less
file to sync manually. However, it also means that an additional keyword
defined in the backend will break compilation as ecpg doesn't have this
definition in its parser.

Does anyone object to moving the symbol definition part to a file of its
own that's inluded by both parser? Or does anyone have a better idea?

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Michael Meskes <meskes@postgresql.org> writes:
> I recently (on my flight to Ottawa) changed ecpg to use the keyword list
> of the backend instead of its own. This means that there is one less
> file to sync manually. However, it also means that an additional keyword
> defined in the backend will break compilation as ecpg doesn't have this
> definition in its parser.

> Does anyone object to moving the symbol definition part to a file of its
> own that's inluded by both parser? Or does anyone have a better idea?

AFAIK bison doesn't have an "include" capability, so I'm not sure how
you plan to make that work?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, May 26, 2008 at 04:15:18PM -0400, Tom Lane wrote:
> > Does anyone object to moving the symbol definition part to a file of its
> > own that's inluded by both parser? Or does anyone have a better idea?
>
> AFAIK bison doesn't have an "include" capability, so I'm not sure how
> you plan to make that work?

You found the weak part in my idea. :-)

How about a small perl script that is run before bison and creates the
real grammar file?

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, 2008-05-27 at 10:03 +0200, Michael Meskes wrote:
> On Mon, May 26, 2008 at 04:15:18PM -0400, Tom Lane wrote:
> > > Does anyone object to moving the symbol definition part to a file of its
> > > own that's inluded by both parser? Or does anyone have a better idea?
> >
> > AFAIK bison doesn't have an "include" capability, so I'm not sure how
> > you plan to make that work?
>
> You found the weak part in my idea. :-)
>
> How about a small perl script that is run before bison and creates the
> real grammar file?

man cpp ?

-------------
Hannu



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, May 27, 2008 at 11:23:28AM +0300, Hannu Krosing wrote:
> > How about a small perl script that is run before bison and creates the
> > real grammar file?
>
> man cpp ?

As this would handle all includes and defines I'm unsure whether it is
desirable.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Michael Meskes <meskes@postgresql.org> writes:
> On Mon, May 26, 2008 at 04:15:18PM -0400, Tom Lane wrote:
>> AFAIK bison doesn't have an "include" capability, so I'm not sure how
>> you plan to make that work?

> You found the weak part in my idea. :-)

> How about a small perl script that is run before bison and creates the
> real grammar file?

If we were going to do that, I'd want it to go all the way and somehow
generate the common parts of the two .y files from a single source.
That'd be enough of a step forward that it would be worth whatever
ugliness is needed to make it happen ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Jun 04, 2008 at 10:21:19AM -0400, Tom Lane wrote:
> Ugh :-(.

This is why I didn't want to go that route. :-)

> I have not spent much time looking at the ecpg grammar, so feel free to
> laugh this off, but I had the impression that all the rules derived from
> the backend grammar have boilerplate action sections (ie, just join the

This is true.

> strings together). So I was hoping that we could leave the backend's
> .y file more or less as-is, and write a perl script that would go
> through it and replace each { ... } action with a suitable cat_str call,
> which it could build on-the-fly by counting the number of rule tokens.

There is some small magic to know when to have blanks in between and
when not, but that should be doable.

> Then combine that output with the ecpg-specific rules taken from a
> separate source file. Obviously there would have to be a few small

This might work. Anyone with good perl knowledge interested?

Michael

--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

I wouldn't mind having a stab at this if you can expand on the 'magic'
required.

(I'm interested because I might be able to use the same logic to roll a third
version of the .y for Aubit4GL outside of the Postgresql tree)




On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
> On Wed, Jun 04, 2008 at 10:21:19AM -0400, Tom Lane wrote:
> > Ugh :-(.
>
> This is why I didn't want to go that route. :-)
>
> > I have not spent much time looking at the ecpg grammar, so feel free to
> > laugh this off, but I had the impression that all the rules derived from
> > the backend grammar have boilerplate action sections (ie, just join the
>
> This is true.
>
> > strings together). So I was hoping that we could leave the backend's
> > .y file more or less as-is, and write a perl script that would go
> > through it and replace each { ... } action with a suitable cat_str call,
> > which it could build on-the-fly by counting the number of rule tokens.
>
> There is some small magic to know when to have blanks in between and
> when not, but that should be doable.
>
> > Then combine that output with the ecpg-specific rules taken from a
> > separate source file. Obviously there would have to be a few small
>
> This might work. Anyone with good perl knowledge interested?
>
> Michael
>
> --
> Michael Meskes
> Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
> Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!



--
Mike Aubury

http://www.aubit.com/
Aubit Computing Ltd is registered in England and Wales, Number: 3112827
Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Mike Aubury <mike.aubury@aubit.com> writes:
> On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
>> There is some small magic to know when to have blanks in between and
>> when not, but that should be doable.

> I wouldn't mind having a stab at this if you can expand on the 'magic'
> required.

Wouldn't it work to just always insert a space between tokens, no matter
whether there was one originally?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

It might depend on the tokens..
Are ">=", "++" etc single tokens ?


On Wednesday 04 June 2008 17:06:44 Tom Lane wrote:
> Mike Aubury <mike.aubury@aubit.com> writes:
> > On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
> >> There is some small magic to know when to have blanks in between and
> >> when not, but that should be doable.
> >
> > I wouldn't mind having a stab at this if you can expand on the 'magic'
> > required.
>
> Wouldn't it work to just always insert a space between tokens, no matter
> whether there was one originally?
>
> regards, tom lane



--
Mike Aubury

http://www.aubit.com/
Aubit Computing Ltd is registered in England and Wales, Number: 3112827
Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers