On Mon, Apr 9, 2012 at 10:53 AM, Geoffrey Irving <[email protected]> wrote:
> It seems like the discussion so far on separate compilation has been > trying for some solution that's better in principle than the C/C++ > module of header files. I guess that I see it the other way around: having started down the type class route, we found (in hindsight) that we needed to have gone down a more exposed path. Given a choice, I tend to prefer something like the CLI approach to the header file approach. It's more in keeping with a range of continuous compilation strategies. But the distinction is mainly about what level of abstraction the code appears at. If we take dynamic linking and library > versioning into account... Once again, library versioning is completely orthogonal. That's a library * naming* problem at the link level, pure and simple. Dynamic linking *per se* is not the problem either, except that in the presence of delayed type binding and consequently delayed method resolution it introduces a requirement for link-time code generation. > Say we have a library B depending on another library A. If we're > trying to replace the current ecosystem of dynamic libraries, we would > like to be able to change and recompile A without touching B at all. > We aren't trying to change that part of the ecosystem. Partly because I was on the [extended] team that specified and implemented ELF dynamic libraries in UNIX, specified their implementation for MIPS, and built *both* of the first two debuggers that handled them correctly. Definitely a problem that I'm not eager to look at again. > This only works if the parts of A that were likely to have changed > were somehow marked as off limits to the optimizer when B was built. > Actually, that's not true. There are a whole range of other design options that can be considered here. > Moreover, the structure of A should be such that B can be compiled by > looking at only a portion of the files of A. That's a nice goal, but it's not how things work in parametric languages. The way to think about this is as follows: - In C++, 10% of the source lines of code are template (i.e. parametric) code. - In BitC, 95% of the source lines of code are parametric. Given the 95% level, a distinction between headers and source for purposes of code generation ceases to make much sense. We still need something that defines interface contracts between libraries, and that has some of the feel of a header file, but it exists for a different reason. > The conclusion seems to be that you either need header files, or you > need to abandon the notion that upstream libraries can be recompiled > without recompiling downstream code. Is this a correct > characterization of the situation? > There are quite a number of other options, so no, I don't think that's a correct characterization. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
