On 09/04/2012 11:52 PM, Jonathan S. Shapiro wrote: > The simple explanation is that Tarditi's analysis of tree shaking was > naive.
I recall you mentioning this before. Has an analysis ever been published? This sounds like a valuable empirical insight worthy of publication. > In consequence, I proceed from the assumption that the /ability/ to > generate and use dynamic shared libraries is a systemic necessity, and > that unreserved reliance on whole-program compilation is therefore an > absurdity. There are clearly situations where one position or the other > can be relaxed. My point is only that there are an overwhelming number > of situations where dynamic libraries are required for performance > reasons, and so a systems language that is incapable of exploiting them > is a non-starter. I was really confused about this note, and after a few days I believe I understand where we crossed signals. Firstly, your original objection to type classes that I was addressing was that they were "too abstract" and impeded inlining. My suggestion of source-based "whole program compilation" was to address *that specific* problem. This discussion of dynamic linking seems entirely orthogonal, since if you're linking dynamically, you've already given up inlining, assuming current linking infrastructure -- although LLVM is beginning to change that. Assuming dynamic linking is also a requirement, that can be accommodated via standard mechanisms and a name-mangling scheme, which I believe you've already done for BitC. Technically, the specialization is then no longer "whole-program", but only a certain "mode" of the compilation where the developer has specified that it's required. Now we reach the crux, which is how do we know when to specialize and when to link? I've suggested before that a 'specialize' keyword would allow developers to declare compile-time specialization requirements, which the compiler must be able to satisfy, ie. source is available. I don't think this is a trivial solution, but I don't think it will require any serious innovation either, and it seems to achieve all goals. So what is the problem with this approach? Sandro _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
