Re: api.header.include and backward-compatible .y files

[Kaz Kylheku]

On 2020-09-19 02:07, Akim Demaille wrote: no.
> *You* seem to believe Bison should not generate the signature of 
> yyparse
> in the header.  But that's Kaz, not the typical use case.  And instead
> of just accepting that, you decided to fight it.

To clarify, I believe that since yyparse is an external name in the yy*
namespace that is traditionally reserved by Yacc, it can be declared in
y.tab.h.  A Yacc program can introduce yy and YY identifiers in y.tab.h
as it sees fit.

So that is to say, if someone does something like this:

  #define yyparse foo(
  #include "y.tab.h"

and there is a syntax error or some other surprising result, that is
their fault. They stuck their fork in a toaster, contrary to the user
manual and common sense.

That's not what I did, though. The yyparse declaration broke all by
itself, without any such interference, by pulling in the
user-supplied parameters.

Of course, I don't think y.tab.h should include any material that
breaks if y.tab.h is cleanly included (unless the programmer asked
for that content via %code or whatever).

I included that workaround in my proposed example/test simply because
it accurately reflect my actual use. I'm not otherwise interested in
this issue. It's "too old to fix", in all likelihood.

I will think of a way to rework that test case so that it works
without the distracting side issue of having to delete anything
from y.tab.h, and yet so that it still captures the same requirements
as the original version of the test case.

> Fighting your tools is certainly one way to have endless problems with
> them.

I'm not sure how I could have predicted that y.tab.h will suddenly
start declaring yyparse.

Now I understand though that the way we avoid fighting with Bison is:

1. Never use a distro packaged Bison. Commit to a particular version.
   Build that Bison version yourself, from its official tarball.

2. Have a "maintainer mode" in your program's configuration. The program
   only runs Bison when configured in maintainer mode. In non-maintainer
   mode, it builds the generated files.

3. When updating to a different Bison version, just fix anything that
   breaks and move on. Fix it using what is evidently the best practice
   under that version of Bison, or else find another version that
   doesn't require the fix or needs less of a fix. (This is where
   we avoid fighting.)

With this workflow, you never have any reason to engage in any
time-wasting interactions with the Bison project, like submitting test
cases or reporting issues, especially if all your requirements
are easily met by decade-and-a-half old versions of Bison.

I would have adopted this practice long ago, if it were spelled out
in the manual!