[Haskell] Re: Trying to install binary-0.4

Simon Marlow simonmarhaskell at gmail.com
Tue Oct 16 08:44:44 EDT 2007

Simon Marlow wrote:
> Claus Reinke wrote:
>>>> - if you provide a 'base' configuration that pulls in the stuff that
>>>>   used to be in base, the package will work
>>> I don't know of a way to do that.  The name of the package is baked 
>>> into the object files at compile time, so you can't use the same 
>>> compiled module in more than one package.
>> i've been wrong about this before, so check before you believe,-) but 
>> here is a hack i arrived at the last time we discussed this:
>> [using time:Data.Time as a small example; ghc-6.6.1]
>> 1. create, build, and install a package QTime, with default Setup.hs
> ...
>> 2. create, build, and install a package Time2, with default Setup.hs
> ...
>> 3. write and build a client module
> Ok, when I said above "I don't know a way to do that", I really meant 
> there's no way to do it by modifying the package database alone, which I 
> think is what Udo was after.
> Your scheme does work, and you have discovered how to make a package 
> that re-exports modules from other packages (I made a similar discovery 
> recently when looking into how to add support to Cabal for this).  As 
> you can see, it's rather cumbersome, in that you need an extra dummy 
> package, and two stub modules for each module to be re-exported.

Ah, I should add that due to technical limitations this scheme can't be 
used to make a base-2 that depends on base-3.  Base is special in this 
respect, GHC only allows a single package called base to be linked into any 
given executable.  The reason for this is that GHC can be independent of 
the version of the base package, and refer to it as just "base"; in theory 
it's possible to upgrade the base package independently of GHC.

So we're restricted at the moment to providing only completely independent 
base-2 and base-3 in the same installation, and essentially that means 
having (at least) two copies of every package, one that depends on base-2 
and one that depends on base-3.

Perhaps we should revisit this decision, it would be better for GHC to 
depend explicitly on base-3, but allow a separate backwards-compatible 
base-2 that depends on base-3 to be installed alongside.

OTOH, this will still lead to difficulties when you try to mix base-2 and 
base-3.  Suppose that the Exception type changed, so that base-2 needs to 
provide its own version of Exception.  The base-2:Exception will be 
incompatible with the base-3:Exception, and type errors will ensue if the 
two are mixed.

If the base-3:Exception only added a constructor, then you could hide it in 
base-2 instead of defining a new type.  However, if base-3 changed the type 
of a constructor, you're stuffed.  Ah, I think we've discovered a use for 
the renaming feature that was removed in Haskell 1.3!


More information about the cabal-devel mailing list