[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: Thu, 15 Sep 2022 13:50:33 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

Hi Kaz (and the Gang);

Sorry about the delay. Life intrudes. I am answering the 'mail' from latest to earliest, so, most likely I am answering things already addressed. Let's just say I'm addlepated and leave it at that (translate that - I dare you).

You're reading too much into what needs to be done. I recognize the mechanisms used to generate compilable and don't mean to change them. But, what is needed is means to detect dependency on our bad boy. Something like bad-boy = something or something = bad-boy. Detection of this dependency defines the order of code insertion.

There are difficulties (fortunately - that keeps our minds occupied and our pockets full). But I'm not sure that they are insurmountable, I am sure that it will take considerable thought, but I don't think it will take considerable code.

As to a heuristic, why? That would be a mystery. Placement should be based on constructing a dependency map. And I admit going though all the includes would be a pistol, but,  I haven't thought this thing through and if you think that it's a time waster, don't do it.

My thought is that dependencies are established via function arguments (fun(bad_boy)), and within data structures (struct name { <type> thing = bad-boy; };), and through simple assignment.

I haven't given it much thought and if its looks like a big job, don't do it. You guys have enough on your plate.

At the End of the Day - your product is great and you're doing a great job. I have used it (and Yacc) on and off for at least 30 years, and look forward to continuing to use it.


On 9/9/2022 10:40 PM, Kaz Kylheku wrote:
On 2022-09-06 13:54, Arthur Schwarz wrote:
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.
Hi Arthur,

The problem is that there is no C, D, Java or anything complete to parse until 
*after* Bison has done its job. Only then do you have a complete file that you 
can feed to some front-end to analyze for dependencies or what have you.

I thought that the whole point of this proposed exercise is to determine how to 
put the program together from fragments in the first place.

The way Bison works is that it needs to generate the correct, buildable output 
in a single pass.

Speaking of passes, one thing you could theoretically do is treat this as a 
search problem. There are a finite number of pieces going into the grammar 
file, and they can be permuted in a finite number of ways, which could be 
searched for a permutation that results in something that compiles.

There is the problem that during development, the code may be wrong, so that no 
permutation of that code combined into a parser source file will compile. Our 
permutation search loop is then sent on a time-consuming fool's errand that 
comes up with nothing.

This is an important point: Bison can generate an output file even when the C, 
D, Java, ... snippets have errors in them. Those are then compile- or run-time 
errors for the language downstream.

Under this search idea, integration with the build would be a sticking point, 
because how the code is compiled varies with the application's build 
environment. Bison output for ostensibly the same language, like C, can be 
built with different compilers in different environments.  That could be 
addressed with some sort of hooks for build integration, which will likely be 
clunky to use.

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.  Except for situations when 
the order is unspecified (in which case the programmer is advised not to depend 
on it). On top of that there can be some mechanism to influence the order, like 
the named sections. That's it.

"... fragile magic ..." Ahem.
I suspect Akim may have been referring to what had been actually tried, in reference to 
named code blocks being developed to "depart from a model where Bison 'guessed' 
where to issue the user's code based on some heuristics".

reply via email to

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