Re: POSIX_ME_HARDER (Was: Bison patch for POSIX and Yacc compatibility with %union)

[Paul Eggert]

Akim Demaille <address@hidden> writes:

> The net result is that the sources are atrocious, error prone,
> intricate, while The Right Thing was elegant and did not hamper new
> extensions in Bison.

If we're talking about the "%union foo {" change, I agree that it
would be much nicer if we could do this in the parser than do it in
the lexer.  The main reasons I did it in the lexer were (1) I don't
know the syntax for C++ well, and some bug reports in this area were
C++-related so I'd like to support whatever C++ needs, and that
requires knowing the C++ grammar to do a parser-based change, and (2)
Bison used to do it in the lexer, so I was sure that the change would
fix the regression.

I would favor further cleanups by supporting this extension in the
parser rather than the lexer, but I'd like to know the answer to (1)
before proposing such a cleanup.  I'd rather not simply reverse the
patch, since I don't want to break backward compatibility without a
compelling technical reason.  And so far, I haven't seen a reason that
is compelling enough.  Certainly I don't want to unduly hamper future
extensions, but I don't know what the extensions you are thinking of
in this area so I don't know what would hamper them and what would
not.


> I also ask for the reversal of the `;'-ending patch.  POSIX is wrong
> when it accepts rules that are not ended.

This suggestion makes less sense to me.  The GNU coding standards
give considerably leeway to ignore POSIX, but they don't give carte
blanche.  Here's a quote from them:

  Standard C and POSIX prohibit many kinds of extensions. Feel free to
  make the extensions anyway, and include a `--ansi', `--posix', or
  `--compatible' option to turn them off. However, if the extension
  has a significant chance of breaking any real programs or scripts,
  then it is not really upward compatible. So you should try to
  redesign its interface to make it upward compatible.

In the case of the ';'-ending patch, any extensions that require an
ending ';' do have a significant chance of breaking real programs.
We know this, because the Bison bug reports told us so.  So we
should try to design extensions to make them upward compatible with
POSIX.  So far I haven't seen why we can't do that.

Also, if we do decide to break POSIX by default, we need to retain
support for POSIX grammars by adding something like a --posix option,
which would be more work for us.


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

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

> 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.

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

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


> I know FU*IX reserved str*, but that's hardly a reason not to use
> struniq, which is so much more in the tone of the language.

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