[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enhancement Request
From: |
Akim Demaille |
Subject: |
Re: Enhancement Request |
Date: |
Sat, 10 Sep 2022 08:39:29 +0200 |
Hi,
Frank and Kaz developed very good points. Let me add a few more.
> Le 10 sept. 2022 à 07:40, Kaz Kylheku <kaz@kylheku.com> a écrit :
>
> 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!