Thomas Lockhart <lockhart@fourpalms.org> writes:
>> Thinking about that, it seems like it might be nice to have a master
>> keyword file that contains just keywords and classifications:
> istm that we would have a better time using gram.y as the definitive
> source for this list.
That's what we're doing now, more or less, and it's got glaring
deficiencies. It's nearly unintelligible (cf Bruce's complaint
earlier in this thread) and it's horribly prone to human error.
Here are just three depressingly-easy-to-make mistakes against
which we have no mechanical check:
* keyword production mismatches token and action, eg
| FOO { $$ = "bar"; }
* failure to add new keyword to any of the appropriate lists;
* messing up the perfect sort order required in keyword.c.
What's worse is that the consequences of these mistakes are relatively
subtle and could escape detection for awhile. I'd like to see mistakes
of this kind become procedurally impossible.
> We could have a perl script (haven't looked; maybe Peter's utility
> already does this?) which rummages through gram.y and generates
> keyword.c.
I believe Peter's already doing some form of this, but gram.y is a
forbiddingly unfriendly form of storage for this information. It'd
be a lot easier and less mistake-prone to start from a *designed*
keyword database and generate the appropriate lists in gram.y.
BTW, another thing in the back of my mind is that we should try to
figure out some way to unify ecpg's SQL grammar with the backend's.
Maintaining that thing is an even bigger headache than getting the
backend's own parser right.
regards, tom lane
