Re: Enhancement Request

[slipbits]

Hi Kaz;

Sorry about taking so long to respond.

Before I say anything, let me state that all comments are due to my 
understanding of Bison. This understanding is a result of reading the 
User's Manual exclusively. That being said, you have more knowledge than 
I because you know the decision process motivating a feature, where I 
just have an understanding of the manual. So, if my questions sound 
dumb, be assured, they are.

>
>
> On 2022-06-17 10:58, slipbits wrote:
> > Given that Bison has the ability to (and does) generate a parser for
> > itself, is there any possibility of removing all %code tags in 
future releases.
>
> This is not clear; remove what from where? For what purpose?
>
> How does Bison being partially self-hosted play into the removal?

What I should have said is that:
1: Bison has complete control of its environment.
2: Bison is facilitated in any changes by using Bison itself.
3: The difficulty of the request is no more than that of a compiler, to 
wit,
   generating a dependency graph.
>
> > This means that one code block, %code { declarations }, is all that is
> > required and removes the placement requirements and discussion in
> > the Bison User's Manual.
>
> By tag, do you want to remove the %code <qualifier> feature?
> From where?

It looks like it is possible to remove all <qualifier>s from all %code 
blocks.
This is  because the Bison generated statements are completely in 
control 0f
Bison and since Bison has knowledge of the working environment, Bison can
elect to move the contents of the declarations in %code blocks with the aid
of a  dependency graph.

>
> The Bison grammar file parse-gram.y uses multiple
> %oode <qualifier> construcs.
>
> Are you looking to edit that file so that it has only one unqualified
> %code block?

That is too particular. I am looking to remove the requirement for 
<qualifier>s
entirely, this would include it's use in parse-gram.y.

>
> Why shouldn't it it have multiple, qualified blocks?
> This is a documented feature of Bison; the Bison grammar is just
> "eating the dogfood", which is good.

The rationale for removal is that it removes a burden from the 
developer. The
developer need not be aware of dependencies (%code require/$code 
provide) and
the effects on the generated parser (basename.<ext>) or header file 
(basename.h).
This "lack of knowledge" means less documentation (potentially), leas 
reading,
and less development considerations for things not directly related to the
project at hand.

In particular with respect to the documentation, the awareness of 
placement in
the generated parser of YYSTYPE, YYLTYPE would no longer be a consideration.

Without the <qualifier>s the developer can use %code blocks anywhere 
with any
content and be assured that placement of %code block contents will allow
compilation, subject to any restrictions included in the Bison User's 
Manual.

With this in mind, let me say that there are differences in behavior and 
code
generation between C/C++. This is an aggravation in the sense that if Bison
agrees that <qualifier>s are not necessary, then Bison may put itself in a
position where it generates function prototypes, and other nasties. But, 
Bison
can also defer these other considerations by documenting things that the 
user
has to be aware of.

What I am saying is that it looks like it is possible. I am not saying that
there is any immediacy. I am saying that I think removing <qualifier>s is a
useful feature, and within the ability of Bison.

>
> Bison ships the generated parser as parse-gram.c, which means that
> it builds without needing an installation of Bison, and the grammar
> file can use the latest features provided in that same version
> of Bison.
>
> Removing the multiple qualified %oode blocks from Bison's own
> grammer would just mean that the feature is exercised less.

What feature?

Is the statement that "without <qualifier> tags, %code blocks would be
used less" what is meant? Doesn't this mean that if you use a feature
less, and get the same result, that the feature is not that important?

>
> The documentation makes it clear that the %code feature makes
> placement less important compared to the traditional %{ ... %}
> Bison gathers code from multiple %code blocks, then catenates
> them together (by qualifier) type. For any qualifier, the order
> is preserved. The code is then generated into the appropriate
> location based on the output type.
>
>

Actually I would disagree. Using %{ ... %} requires that the user
know about the placement of YYSTYPE and YYLTYPE in the generated
files, the placement of the block being up to the user. Use of the
$code blocks allows Bison to do correct placement of code, but the
knowledge about YYSTYPE and YYLTYPE is still required.