> 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:
Zounds! How could this ever have worked??!! ;)
> 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.
No disagreement with the goals...
> 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.
Certainly gram.y is forbidding to beginners and those who don't spend
much time in the code, but separating blocks of the code into external
files only increases the indirection. One still has to *understand* what
gram.y is doing, and no amount of reorganization will keep one from the
possibility of shift/reduce problems with new productions.
One possibility would be to put better comments into gram.y, and to back
those comments up with a validation script that *could* generate
keyword.c and other cross references. A bit more structure to the
comments and code would enable that I think.
> 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.
That would be nice. Unfortunately that would lead to the main parser
having the same machinations used in ecpg, with separate subroutine
calls for *every* production. Yuck. I wonder if some other structure
would be possible...
- Thomas