[Top][All Lists]

[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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]