2008/10/3 Mitchell, Neil
Hi
You mean shared libraries without the opportunity to inline library code? This would result in a huge performance loss, I think.
Usually _mild_ performance loss, in exchange for major code-size savings, I would think. C obviously has worked quite fine under exactly this restraint (though C implementations obviously aren't built to take as great advantage of inlining library code as Haskell may be).
I think that the performance loss is much higher in the case of Haskell because of Lazy Evaluation, massive use of higher order functions and possibly more.
Example 1:
foo x | "test" `isPrefixOf` xs = ... | otherwise = ...
If you have cross-module inlining, you get the rather obvious if like construct. If you don't, you have to evaluate otherwise and test its value.
Example 2:
(a :: Int) + b
If you have cross-module specialisation you get a primitive integer arithmetic instruction (possibly with a bit of unboxing, although often not). If you don't, you get a dictionary lookup, followed by a higher order application.
One reason cross-module inlining is essential is that many Haskell functions don't do very much, think of (+), (||), (>>), not, otherwise etc. In C these would be built-in's, so are always available to the optimiser (and usually just one instruction), in Haskell you need to get them from the Prelude.
What happens in the C++ world where good chunk of functionnalities are in header files (templates or inline methods); is there the same LGPL problem that the one discussed here w.r.t. static/shared linking ? Thanks, Thu