Re: Enhancement Request

Akim Demaille <[email protected]> Sat, 10 Sep 2022 08:39:29 +0200
Newsgroups gmane.comp.parsers.bison.bugs
Message-ID <[email protected]>
Hi,

Frank and Kaz developed very good points.  Let me add a few more.

> Le 10 sept. 2022 =C3=A0 07:40, Kaz Kylheku <[email protected]> a =C3=A9cri=
t :
>=20
> When you think about it, a tool like Yacc should have a simple =
specification: most of the code snippets in the second language should =
appear in the output in the same order as they appear in the grammar =
file.

This sounds natural, but stems on a couple of issues.

First, there is not always one single answer.  Since Bison also =
generates the header file, in one way or another the developper must be =
clear on what is public and should go there, or remain private and stay =
in the .c file.  Dependencies won't answer the question here.  It's a =
design decision that has to made, and specified, by the developper.

Second, YACC tries to be fairly liberal wrt order.  For instance

%token <ival> INT
%union {
  int ival;
  float fval;
}
%token <fval> FLOAT

the order here is irrelevant and it is not required from the developper =
to stick to an order where definitions always precede uses.  So the =
order of the directives is fairly meaningless.

Finally, a feature that has been asked for several times is a form of =
modularity where you would be allowed to %import grammar bits from =
elsewhere.  In this case, of concept of "order" is even less clear.  =
(This feature is not under development, but I still think about it.  As =
a matter of fact, some features (e.g., split %union) were implemented =
precisely to facilitate the implementation of %import once we go for =
it.)


So summarize:
- it would be immensely difficult to implement (because of the target =
languages)
- it would be very costly to run
- it would be fragile
- it would make build rules incredibly difficult (e.g., this foo.h file =
that is used in the grammar needs to be generated before)
- it's impossible to do independently of the target environment (i.e., =
we break the idea that Bison generates a unique output, =
target-independent)
- etc.


Really, learning a few %code tags is way simpler.  Not just for us, =
Bison developers, but also for Bison users, and for users of =
Bison-generated files.

Cheers!=