[Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies

[Paolo Giarrusso]

On Sun, Sep 12, 2010 at 20:46, Tillmann Rendel
<rendel at mathematik.uni-marburg.de> wrote:
> Paolo Giarrusso wrote:
>> in a tracker entry you linked to,
>> http://hackage.haskell.org/trac/hackage/ticket/704, duncan argues that
>> "we also want to be able to do things like linking multiple versions
>> of a Haskell package into a single application".
[snip]
> Even with the technical ability to link all of foo, bar, pair-1 and pair-2
> together, I don't see how this program could be reasonably compiled.
> Therefore, I think that the notion of consistent install plans is relevant
> semantically, not just to work around some deficiency in the linking system.

Your case is valid, but OTOH there other cases to support: if I link
together two programs which use _internally_ different versions of
regex packages, cabal should support that - and here I guess we agree.

The issue is how to express or recognise the distinction.

I had this kind of scenario in mind, and that's why I proposed using
versioned typenames for typechecking - your example program would then
be caught as ill-typed. However, that's not enough, because the
correct solution is to use the same pair version.

- OTOH, Program would probably have its own cabal file, which could
maybe list a dependency on pair. But I don't like this solution - the
developer shouldn't have to do this.

- The nicer alternative would be to extract, from the types used in
the .hi files, whether they mention pair at all - like here, and
unlike the case when the different packages are used internally. This
solution is perfect but takes extra work which I can't estimate.
Actually, some more work would maybe be needed to cope with
cross-module inlining, but I believe that this can be done by cabal,
by just "looking at" .hi files, without further changes to GHC - after
versioned typechecking is introduced if missing, anyway. And maybe
some interface to .hi files should be exposed.
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/