[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enhancement Request
From: |
Akim Demaille |
Subject: |
Re: Enhancement Request |
Date: |
Sun, 4 Sep 2022 10:23:50 +0200 |
Hi,
> Le 20 juin 2022 à 22:02, slipbits <home@slipbits.com> a écrit :
>
> Hi Kaz;
>
> Sorry about taking so long to respond.
Compared to my speed, you are almost relativistic.
> > 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.
IIUC, you are suggesting that Bison should guess where to place the various
code blocks, depending on their content instead of their name/tag.
There's a number of reasons that go against this:
- first and foremost, code blocks are black boxes to Bison. It does not parse
them, and never will. That would require whole (compiler) frontends for all
the languages we support, which will never happen.
- the "dependencies" might be hidden. For instance in C, a #include might be a
provider of something another would be consumer of. Sure, if we have a
complete C frontend, the problem is solved :)
- we actually invented named blocks to depart from a model where Bison
"guessed" where to issue the user's code based on some heuristics. It was
confusing, resulted in many users puzzled by drastic changes in the generated
parser because of apparently minor reordering in the source file.
- being picky is definitely not very novice-friendly, but predictability is far
more important. Dumb but clear rules are often superior to fragile magic.
- many of these code blocks are specific to the target language, and baking
into bison-the-executable the resolution of these dependencies would ruin the
fact that today people can have their own skeletons, possibly for languages we
are unaware of.
I'm sure that are other issues.
> What I am saying is that it looks like it is possible.
I don't believe it is. I can perfectly understand the desire to have a thiner
documentation, and more automation, but in this precise case, I'm fairly
confident the implementation cost would be enormous, for a marginal win.
Cheers!
- Re: Enhancement Request,
Akim Demaille <=