Re: GNU bison suggestion: some include directive.

The best use-case for %include in Bison does not involve splitting a
single grammar up into multiple translation units.  The best use-case
is for developing a suite of common "grammatical sub-phrases", each
of which can then be referenced from multiple bison grammars.

A Bison source file has 5 sections, which I will name as follows:

	C_Declarations
	Union_Items
	Grammar_Declarations
	Grammar_Rules
	Additional_Code

This complicates any %include facility, as one would want each such
"grammar header" file to be able to contain all 5 sections (if necessary).

I accomplished this on a large project by using M4 macros to create a
pre-processor that reads a ".g" file (and perhaps additional ".gh" header
files) to produce a single ".y" file read by Bison.  The 5 section names
above are M4 macros that simply change the buffer into which M4 "diverts"
all subsequent text.  Upon detection of EOF, these macros assemble each of
the 5 diversion buffers into a single Bison source file with the 5 sections
properly delimited and in the correct order.  There is also an
Include_Grammar(foo.gh) macro that performs the inclusion (and also
implements an automatic "include guard" functionality).  Note that this
macro must also save and restore the current diversion.

This pre-processor also has a mode for automatically generating "make
dependencies".  (This functionality depends upon a "--makedep" feature that
was contributed to M4 (and accepted) many years ago, but which the M4
maintainers have failed to include in any subsequent release.)

If Bison were to natively implement %include, it should probably allow
each included file to have the "standard Bison syntax" delineating these
5 sections, and do the "interleaving" of these sections internally.

For Bison, a simple "textual" %include facility is essentially useless.

David

On 8/9/23 15:37, Frank Heckenbach wrote:
> Basile Starynkevitch wrote:
>
>> In some cases, a GNU bison input grammar might be a too big file, and it
>> would be convenient to have some include directive (à la GNU cpp) in it.
>>
>>
>> Spliting a large grammar file into several pieces is convenient, for
>> software engineering reasons (exactly for the same reason, C and C++
>> have #include....)
> C and C++ can split a program into translation units, i.e. different
> source files, that are compiled separately. This necessitates
> headers to hold shared declarations. Same for libraries.
>
> This is different for Bison. A Bison parser is always a single
> translation unit. (Though it can be a translation unit of a C or C++
> application, but the parser itself cannot be split.) This removes
> the main application of includes in C and C++.
>
> The only use left that I can see is if you can split a grammar in
> such a way that textual inclusion works. In my experience that's
> difficult because the Bison grammar is intertwined with semantic
> actions. I have two grammars with a very similar subset (expression
> syntax), yet I haven't been able to unify them in a way that
> includes would work (if available) because my classes that implement
> the semantic actions are different, and it's only a small part
> (perhaps 1/3) of the whole grammar, anyway.
>
> Your experience may be different. I'm just saying it's not as
> obvious as it may appear and not such a compelling argument as in C
> and C++ (before C++ modules, anyway).
>
>> I would even like to include a popen-ed output, if explicitly allowed by
>> a --popen-allowed program option. Then %| would popen the command and
>> include it.
>>
>> Is that suggestion interesting someone?
> I'm not a Bison developer, but I'm even more skeptical here. I think
> the Unix principle applies, do one thing well. It takes one rule in
> a makefile to save the command's output in a file, with the extra
> benefit that the command doesn't have to be rerun if only other
> parts of the grammar change (for an extreme case, consider a grammar
> that popen-includes dozens of commands' outputs and having them all
> rerun if one of them changes). That's what make does well already.
> (Also, even with this feature, you'd have to list all those
> commands' sources and inputs as dependencies in the makefile,
> anyway.)
>
>> (it would be very useful in the RefPerSys open source -GPLv3+ licensed-
>> inference engine project onhttps://github.com/RefPerSys/RefPerSys/  ....)
> That's a big project, so perhaps you could tell us which files in
> particular to look at.
>
> Regards,
> Frank
>