Re: Enhancement Request

[Frank Heckenbach]

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.)