[Haskell-cafe] package dependencies should distinguish between API and implementation?

[Alexander Kjeldaas]

On Mon, Feb 25, 2013 at 12:50 PM, Johannes Waldmann <
waldmann at imn.htwk-leipzig.de> wrote:

> 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)
>
>
There's a third relation, A API-ABI-depends-on B iff some type of B is used
in the hidden binary representation that is used in backing the API visible
to A.

Alexander


> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130225/065c54a5/attachment.htm>