Обсуждение: [I|S]CONST/[I|S]const in gram.y
Hi, is there a reason why we sometimes use ICONST and SCONST directly in a rule in gram.y yet in other rules use Iconst and Sconst which in turn resolve to ICONST and SCONST? Some rules even use ICONST and Sconst, so there does not be any consistency. If this has no reason I'd like to make all rules use the same symbol which will make gram.y be consequent in its symbol usage and simplify my work to generate the ecpg parser out of an unchanged gram.y at the same time. 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:
> is there a reason why we sometimes use ICONST and SCONST directly in a rule in
> gram.y yet in other rules use Iconst and Sconst which in turn resolve to ICONST
> and SCONST? Some rules even use ICONST and Sconst, so there does not be any
> consistency.
Seems like an obvious no-op.
> If this has no reason I'd like to make all rules use the same
> symbol which will make gram.y be consequent in its symbol usage and simplify my
> work to generate the ecpg parser out of an unchanged gram.y at the same time.
Which direction are you hoping to go --- remove Iconst/Sconst, or use
them everywhere?
regards, tom lane
On Mon, Nov 10, 2008 at 08:12:49AM -0500, Tom Lane wrote: > Which direction are you hoping to go --- remove Iconst/Sconst, or use > them everywhere? For ecpg I don't care, I have to make some changes during translation anyway. Right now my script just sets both to ecpg_iconst. There is a small advantage in keeping Iconst/Sconst as it might save me a line or two in the script. As for the backend I would say that removing Iconst/Sconst make sense. These rules just add an overhead, albeit a very small one. But still this advantage outweighs the very small scripting advantage. So yes, I'd remove Iconst/Sconst. 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 10, 2008 at 08:12:49AM -0500, Tom Lane wrote:
>> Which direction are you hoping to go --- remove Iconst/Sconst, or use
>> them everywhere?
> For ecpg I don't care, I have to make some changes during translation anyway.
> Right now my script just sets both to ecpg_iconst. There is a small advantage
> in keeping Iconst/Sconst as it might save me a line or two in the script. As
> for the backend I would say that removing Iconst/Sconst make sense. These rules
> just add an overhead, albeit a very small one. But still this advantage
> outweighs the very small scripting advantage. So yes, I'd remove Iconst/Sconst.
I experimented with doing this and found that things seemed noticeably
uglier; for example in createdb_opt_item we have (ignoring the actions)
| TEMPLATE opt_equal name | TEMPLATE opt_equal DEFAULT | ENCODING opt_equal Sconst
| ENCODING opt_equal Iconst | ENCODING opt_equal DEFAULT | COLLATE opt_equal Sconst |
COLLATEopt_equal DEFAULT
which'd become
| TEMPLATE opt_equal name | TEMPLATE opt_equal DEFAULT | ENCODING opt_equal SCONST
| ENCODING opt_equal ICONST | ENCODING opt_equal DEFAULT | COLLATE opt_equal SCONST |
COLLATEopt_equal DEFAULT
which at least to me seems confusing --- the ICONST and SCONST
occurrences look like literal keywords rather than token classes.
So I find I have a mild preference for the mixed-case spelling.
One possible way to shave the cycles and still have it look nice
is to rename the actual tokens produced by scan.l to Iconst and Sconst;
but this might be more trouble than it's worth. Thoughts?
regards, tom lane
On Mon, Nov 10, 2008 at 01:41:23PM -0500, Tom Lane wrote: > I experimented with doing this and found that things seemed noticeably > uglier; for example in createdb_opt_item we have (ignoring the actions) > > | TEMPLATE opt_equal name > | TEMPLATE opt_equal DEFAULT > | ENCODING opt_equal Sconst > | ENCODING opt_equal Iconst > | ENCODING opt_equal DEFAULT > | COLLATE opt_equal Sconst > | COLLATE opt_equal DEFAULT > > which'd become > > | TEMPLATE opt_equal name > | TEMPLATE opt_equal DEFAULT > | ENCODING opt_equal SCONST > | ENCODING opt_equal ICONST > | ENCODING opt_equal DEFAULT > | COLLATE opt_equal SCONST > | COLLATE opt_equal DEFAULT > > which at least to me seems confusing --- the ICONST and SCONST > occurrences look like literal keywords rather than token classes. > So I find I have a mild preference for the mixed-case spelling. Fine with me too. Actually I don't think we'll waste a lot of cpu cycles when keeping the Iconst/Sconst rules as they are. > One possible way to shave the cycles and still have it look nice > is to rename the actual tokens produced by scan.l to Iconst and Sconst; > but this might be more trouble than it's worth. Thoughts? I agree that this is not worth it. After all the mixed-case spelling looks like a non-terminal and at some point people will spend time looking to the rules defining these non-terminals. 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!