Cabal and GHC

[Gábor Lehel]

On Thu, Nov 22, 2012 at 8:41 PM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> On Thu, 22 Nov 2012, Brandon Allbery wrote:
>
>> I am wondering if we're trying to solve the problem in the wrong way.  The
>> core of the problem is that various things get baked into libraries in the
>> name of optimization, such that a given binary library has dependencies on
>> precise versions of other libraries; it's not like C where anything
>> supporting the ABI can use the same .a/.lib or .so/.dll/.dylib.
>
>
> C supports inlining. This should cause the same kind of problems, shouldn't
> it?

Indeed, and in Qt for example which has a strict binary compatibility
guarantee, making a public function inline means you effectively
cannot change it until the next major release. (In this case "making
it inline" and "including the definition in the header file" are
effectively synonymous, one requires the other.)

The problem is that in Haskell inlining is a lot more important for performance.

>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
Your ship was destroyed in a monadic eruption.