Package dependencies are modelled by a relation "A depends-on B".

Shouldn't this in fact be two relations:
API-depends-on  and  implementation-depends-on?

(meaning that  A API-depends-on B
iff some type of B is visible to the user of A)

So what we currently have is  implementation-depends-on
and  API-depends-on  is a sub-relation of that.

The point being the following: assume

* A implementation-depends-on B.1
* not (A API-depends-on B.1),

* U implementation-depends-on A
* U implementation-depends-on B >= 2

Then U (indirectly) implementation-depends
on two versions of B but it should still be safe?
(e.g., I can install B.3, re-compile U, but keep A)

Example: A = template-haskell, B = containers
(at least I don't see any mention of Data.Map/Set in  th's API,
I think the only dependency is in the implementation of PprM
http://hackage.haskell.org/packages/archive/template-haskell/2.8.0.0/doc/html/Language-Haskell-TH-PprLib.html
)

or in general, A (and B.1) are baked into ghc,
but there is some B.2/B.3 out there which U wants to use.

Or is this what already happens? (ghc would notice
that B.1.foo is different from B.2.foo.
cabal-install would warn, but proceed?
Then the effect of the proposal would just be
to switch off these warnings in some cases?)

- J.W.


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe