[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] examples: add new build scenario test case
|
From: |
Kaz Kylheku |
|
Subject: |
Re: [PATCH] examples: add new build scenario test case |
|
Date: |
Wed, 23 Sep 2020 18:35:59 -0700 |
|
User-agent: |
Roundcube Webmail/0.9.2 |
On 2020-09-23 12:27, Akim Demaille wrote:
Hi Kaz,
Le 20 sept. 2020 à 22:01, Kaz Kylheku <kaz@kylheku.com> a écrit :
On 2020-09-19 02:44, Akim Demaille wrote:
Hi Kaz,
I guess this example can be used as a basis to discuss of "one
feature at a time", as I mentioned in the other thread.
I fully disagree with what you are doing here. You completely
discard features that have been designed to address your exact
needs: specifying what goes into the headers. That's the point
of "%code requires" and "provides", introduced in Bison 2.4 (that's
twelve years ago!). These features are so obviously needed that
even Byacc features them now.
Byacc added %code in November 2019; it has not even been a year!
I will definitely look into using %code provides, maybe in a three
to five year time frame.
So I'm afraid there's nothing I can do for you. You have framed
yourself into too constrained a set of requirements.
Well, the grammar file is meeting all my requirements;
using %code would only be a refactoring which preserves exactly
the same functionality, with no benefit to the end user.
The maintainability is about the same; it's the same pieces
of code, just moved around.
The productive approach is to process it with the correct version
of the correct tool, that is all.
(The multiple start symbol feature you are working on could
make a meaningful improvement to my code by removing the hacks
I came up with to bring it about.)
You refuse
to ship generated parsers
No; I have changed my mind about this. Clearly, this the way Bison
is intended to be used, communicated by the project maintainer,
and also by the GNU project as a recommended practice.
Little build details breaking between Bison releases are
expected behavior, and it makes no sense for the project to try
to cement those things in place with test cases.
Bison could work that way (if the compilers for major, standardized
languages can do it, a parser generator certainly can), but it's a
big demand and shift in direction, which takes away "cycles" from
other work.
you refuse to emit requirements over
the version of the generator, you refuse to embrace the idioms that
That's probably a non-starter; you can't tell the the regular
user, please have Bison 2.5 ready for my program to build.
No package maintainer for any distro will take on your program if
do things like that.
have been designed more than ten years ago (!) to address your
problems, you refuse to choose once and for all between byacc and
bison, etc. so you are just outside our scope.
Just, it would be good for all this kind to be loudly documented.
The GNU Bison manual should state something like:
- the best practices given by examples are subject to change
- though backward compatibility is an important goal, users
are encouraged to retain generated parsers. Generated parsers
are intended to be portable among C compilers, more so
than grammar files among parser generator versions.
- striving for compatibility of grammar files among multiple
different generators, especially if features beyond POSIX are
involved, is not recommended: it will require less effort
to commit a project to using a specific parser generator,
whether that be Bison or something else.
I can try to rework the test case so that it doesn't do the sed
hack for removing yyparse from y.tab.h, yet still covers everything
that is salient, in order to keep it working.
I will not install your test case. For instance you still
have not understood that the examples are show cases, they are
No, I understand that. The examples should show best practice.
(And happen to be covered by test cases, but that is not
their main point.)
It's clear that filtering the y.tab.h file can never be looked
on as a good practice. I would never suggest such a thing.
You seem to now be communicating that even if that issue is resolved,
the example still isn't good practice. It's perhaps only good
practice on versions of Byacc before November 2019 which don't
have %code, and decade or more old versions of Bison. I won't
bother working on it, therefore.
(In any case, I chose that area of the tree to do the work because
it was the best fit technically: it contains examples made of
separate files, with nothing being generated by M4 macrology,
and provides test cases for them which have to pass. It was not
because I don't understand the purpose of examples.)
the exact opposite of what you are looking for: these examples
will always be updated to demonstrate the best approach with
the current release of Bison.
Right, and so then the old example is gone, and no longer
being built or tested. That's the same thing as asserting that
the practice which that example recommended in that version of
the tool is no longer recommended now. Fair enough.
The following commit shows how this example should look like.
I've made it available as https://github.com/akimd/bison/tree/kaz
if you want an easier access.
Is there no existing example with a test case covering this?
Of course it's covered by the test suite. And I trust you
know how to play with git grep to look for that by yourself.
But that doesn't negate the validity of the original.
You like to claim that, and you did that for five years now:
"hey, look at that! I could write that ten years with Bison 2.x,
and Bison 3.x breaks this!".
I now understand that well-defined Bison 2.x code is not
well-defined Bison 3.x, even if in cases in which we cannot
use documentation to pin down exactly why. The old code didn't
violate anything in its applicable spec, but something breaks.
Though the code didn't violate anything, it's doing something
in a way that doesn't exactly conform to an example in 3.x.
The gold standard is: make your code as close to the examples
in the documentation of the version of Bison you're committed
to using. That's it.
Laser-accurate backward compatibility is not a universal
value that all projects have to accept, and projects should
not be chided for not adhering to a value they have not
expressed as adopting for themselves.
You don't care about any of the suggestion I made. You just
keep on explaining how incredibly bad Bison is maintained.
I am sorry about that; it is unfair. I now see it differently.
Well, I spent quite some time on the problems of Kaz Kylheku,
and now I will spend more time on the problems of Bison users.
Which is also clear: I am obviously not in the set of
"Bison users". "Bison users" are those who track the
development of Bison and try new features.
A Bison 2.5 user or a Bison 3.0 or 3.4 user is not a "Bison user"
in this regard.
If the Bison 3.0 user finds that their code doesn't work
with the current Bison in some way, then that is not in the
scope of "problems of Bison users". It's also not in the scope
of problems of Bison 3.0 users.
The problem is really in the scope of "idiot user". Bison 3.0
users who aren't idiots run Bison 3.0 (which is what defines
them as Bison 3.0 users) and everything is fine.
It is self-evident that those who are not Bison users with
Bison user problems shouldn't disturb the Bison project with noise.
I have never believed otherwise; I just had the set definitions
and relationships wrong.