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!=