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 on https://github.com/RefPerSys/RefPerSys/ ....) That's a big project, so perhaps you could tell us which files in particular to look at. Regards, Frank