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

> Le 21 sept. 2020 à 10:15, Kaz Kylheku <[email protected]> a écrit :
> 
> On 2020-09-19 02:07, Akim Demaille wrote: no.
> 
>> 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.

The same complain as five years ago?  Seriously?

https://lists.gnu.org/archive/html/bug-bison/2015-08/msg00006.html

Could we just move forward?


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

Of course, that's an overstatement.  Most grammar files don't have
such problems.


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

You may call this a maintainer mode if you want (Bison for instance
does not have one), but yes, *shipping* the generated files buys
you freedom, and relieves your users from your requirements.
Don't commit the generated files, just ship them.


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

You are currently mostly concerned with "mandated" updates to
your files (i.e., adjustments required by newer versions) because
that's currently the problem at hand you are striving to address.

But I claim that once you made that jump to using %code etc. (which,
I agree, is painful for you, but brings you from a distant past
to only twelve years ago) then 

(i) you will see that we pay attention to backward compatibility,
  so you should not have this kind of problems soon
  (there are still old things that I'm getting rid of, e.g., YYPRINT,
  so I'm not claiming it will never happen again, I'm just saying
  that it's not as frequent as you depict it).

(ii) you will be more likely evolve your grammar files to benefit
  from new features.  _If_ you ship your generated files, then
  you will be freer to use more recent features to simplify your
  parser.  I'm not suggesting you should jump to the bleeding edge
  release, but wait for say half a year so that the Bison release
  is widespread enough for your casual contributors to have it
  on their distros.  The end users, and the distros, will not
  have any such issues, since your tarball is self contained and
  independent of Bison being installed or not. 


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

You loaded this paragraph with tons of irony, which is a pity,
because you were making a lot of sense.  Shipping the generated
parsers will also allow you to kiss bison bye bye, and play it safe
by using byacc only.

Please, do that.