Re: Reserved name classes

[Akim Demaille]

 >> I also just discovered the following change, that I have not seen on
 >> bison-patches, but maybe I just missed it:

 Paul> It is archived in
 Paul> <http://mail.gnu.org/archive/html/bison-patches/2002-12/msg00007.html>.
 Paul> However, the GNU mail server was flaky for the past month or so, so
 Paul> I wouldn't be surprised if it never hit your mailbox.

Heck.  I discovered others too there :( Thanks for the reporting the
location.


 >> Actually, we could have decided to go on with s/(\w+)_t/a_$1/, after
 >> discussion.  But that huge smashing of the ids kills it all.

 Paul> If we want to change the names again, to something like a_state, I
 Paul> will volunteer to do the legwork.  It wouldn't be that hard.

Of course it would be: you smashed the var names too.  What _is_ easy
is remapping "state" to "a_state".  But how will you restore all the
"s" back into "state"?

I spent full days of my spare time of my weekends changing the
(*&$£(*&$^ sp1, sp2, s, p, r and other names into something that could
make the Bison core engine readable.  Now, we are back to `s' which
can be a state, a state number, etc. etc.

 Paul> However, I must confess that I found the code to be more
 Paul> readable after the trailing _t's got removed.  

Well...

 Paul> Ending each type name in "_t" reminded me too much of Hungarian
 Paul> notation.  And the numerous "state_t *state;"s and "rule_t
 Paul> *rule;"s in the old code got me to worrying that I had double
 Paul> vision.  To my eye the new "state *s;" is more readable than
 Paul> the old "state_t *state;", at least in the Bison code.

I found precisely the converse, and it took me months to have some
form of homogeneity.  But more was needed, and now I'm just depressed
thinking about this.

I had chosen type_t and struniq perfectly knowing that I was
infringing the warning of POSIX, that I was putting myself under my
own responsibility.  It was not for free.  It was not for free that I
stayed in front of my computer on sunny Sundays.

My hope is that no inconsistency was introduced in the variable names,
and that `s' is *always* the name of a state, not of anything else.

 Paul> The C standardization committee has long been opposed to having
 Paul> str* functions that do memory allocation; that is why strdup is
 Paul> not in the C Standard.  So I suspect the committee would
 Paul> disagree with you about the tone of the name "struniq".  (The
 Paul> committee is not always right, of course.)

Well, I still know pretty many projects using strdup anyway so I guess
that the `tone' I'm referring to is not theirs.  That's no news :)