On Mon, Apr 9, 2012 at 6:23 PM, Sandro Magi <[email protected]>wrote:
> The open source ecosystem disproves > your proposition that the set of realistic programs that can be whole > program compiled is empty. It does not. But before I explain why, let me say thank you. One of the things I have loved about this list and the EROS/Coyotos lists is the quality of the participation. Someone will put forward a position, various people will discuss it. In the process, it is often true that unstated assumptions are revealed [as will momentarily be true here]. I think that one of the hardest things in engineering is to discover and exhume unstated assumptions. Thanks to all of you for participating in that process. OK. Back to the topic. The reason Sandro is mistaken is that [un]availability of source is not the impediment to whole-program compilation. If we proceed from the assumption that all source code is universally available, whole-program compilation is still inadvisable. The simple explanation is that Tarditi's analysis of tree shaking was naive. Systemic performance at multiple levels of abstraction *demands* code sharing across programs. But the fundamental assumption of whole-program compilation is that no code sharing across programs will result. 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. A Cabal/CPAN/Gems-like repository for source is the viable technical > answer to the technical challenge you raise above... Given that the problem is not and never was source availability, I hope you now see why I do not agree. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
