[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enhancement Request

From: Arthur Schwarz
Subject: Re: Enhancement Request
Date: Tue, 6 Sep 2022 13:54:46 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0

Hi Akim;

After a while I decided, why not. I might just as well answer you. Thanks for your response. This will be a summary and not a point-to-point answer. It is clear that Bison does not want to, and will  not, proceed forwards, and so, take this as me just grumbling in my cave.

I do think the effort is moderately difficult. I do not believe it is as hard as you have indicated. The languages you generate Bison for is modest, and the semantics are similar (a caveat here since I don't know D). If you don't want to develop you're own parser, then you can always fiddle with the gcc (https://gcc.gnu.org/) front end to get a desired result.

"... fragile magic ..." Ahem. No sense going into hyperbole. This one is out-of-line and  unnecessary. The idea proposed is to construct a dependency graph, usage graph, of variables with respect to our bad boy, and to do code reorganization based on the results of the graph. Now the first book on optimization I read was written in about 1969 (Cock and Schwartz) and I believe had a dependency graph. Some compilers allow output of a dependency graph, and certainly optimization requires it. Unless an implementation is poor and ill-defined in some sense, it shouldn't be magic and it should be robust in the developers sure hand.

As to "confusing", if you say so. But, if it works then it is a "black box" to the users. If it doesn't work then the user has done something wrong, and this should not be part of it. Let's look at an optimizing compiler for a moment. Optimization reorganizes code on a regular basis. Someone looking at the code generated will certainly be confused by what is seen, and this is no more confusing than the proposed method.

The substantive points brought out are well taken, in particular, that Bison allows output to heretofore unknown languages by use of a skeleton. Good point in that automatic generation of a dependency graph depends on language semantics and an unknown language has no Bison known semantics.

Lest we get carried away, this is your product and you are free to do as you wish. My history with your product, and its predecessor, Yacc, is that I am impressed. It is very, very good.

Please ignore what you want.


On 9/4/2022 1:23 AM, Akim Demaille wrote:

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.


reply via email to

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