Arthur Schwarz wrote: > After a while I decided, why not. I might just as well answer you.
So let me take the freedom to reply to your answer instead of Akim. ;) > "... 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. I don't think Akim said that implementing a dependency graph is hard or fragile. I'm sure he can do this easily (as can I FWIW). The problem is getting the correct inputs to that dependency graph which was his main point (IMHO) which you didn't even address, apart from a laconic statement: > 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, By which metric, please? One of the target languages in C++, and I don't think anyone has ever called it modest in any way. :) Dependencies via template instantiations, namespaces, argument lookup etc. are hard to detect without full (not superficial) parsing of the full input and all include files (which depend on the compiler, its version, standard version and more). Have you written a correct parser for modern C++, for instance? I doubt it. (Actually, I doubt anyone has, but that's another topic ...) Even if you have, do you think such a parser *should* be part of Bison? Furthermore, as he wrote: > > - 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 :) Actually, I think he's being too optimistic here. A C/C++ header could easily use ifdef's in a clever (read, abhorrent) way such that dependencies depend (sic!) on the target system, compiler version, user-defined conditionals etc. A normal C frontend (including preprocessor) handles one given set of conditionals. What would be needed here would be one pass that determines all possible sets of conditionals that result in different branches being preprocessed or different defines that may influence dependencies, then running the preprocessor and frontend for each such set to determine the respective dependencies, and finally producing output that contains generated ifdef's to put the code blocks in the right places according to those dependencies. This is not only as ridiculous as it sounds, but may also suffer from combinatorial explosion (read, exponential runtime) and produce incomprehensible output. If that's not enough, consider compiler options. There are many options to the various compilers, but I think a single one is already a knock-out, namely "-I". This option allows the user at compile-time (i.e., after Bisons runs), to basically swap out some or all included files for totally different ones with different dependencies. (And that's not hypothetical, think e.g. cross-compiling.) I think the best one could possibly do is to add generated checks that inform the user that the current dependencies are not what they were when Bison was run and to please rerun Bison with a matching set of options. Doing this rigorously will have further complex consequences for authors of Makefiles and build systems which suddenly need to pass way more options to Bison that it so far doesn't have to care about. Finally (probably not, but I'll leave it at that), it would make Bison's output dependent on all input of the target code which it isn't so far. I.e., if you change something in a .h file of your project, you don't only need to recompile (like now), but also rerun Bison as your change may affect the dependencies Bison relied upon. (Which in turn makes Bison a build-dependency of any project that uses it, which it isn't now if the project ships Bison's output.)