Cabal and GHC

[Simon Marlow]

On 22/11/2012 19:54, Gábor Lehel wrote:
> 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.

I would like to see GHC support fixed ABIs, and the work I did with ABI 
hashing in GHC was aiming towards exactly that.

For fixed ABIs you would need to have the user explicitly declare every 
inline function, and then hash the definitions as part of the ABI. (also 
do something about strictness and arity, and other cross-module 
optimisation hints).  It might be painful, but it could be optional, and 
the gains are quite nice: the ability to upgrade a library in-place 
without recompiling everything that depends on it.  Especially now that 
we're moving towards shared libraries, this would become more useful.

I'm sure it's not going to happen soon, but it would be an interesting 
project for someone (probably larger than a GSoC project though).

Cheers,
	Simon