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