Re: [Haskell-cafe] package dependencies should distinguish between API and implementation?
On 13-02-25 06:50 AM, Johannes Waldmann wrote: 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?) GHC uses both versions of B as much as possible. If none of the following 3 problems occur, they co-exist peacefully. B defines a type T and/or a type class C. GHC considers B-1.T and B-2.T different and not interchangeable; similarly C. This is fine if one version is merely implementation-depended on. This becomes a visible type error if both versions are API-depended on and you try to mix them. You will see type errors like "cannot match B-1.T with T" or "T is not an instance of B-1.C". (Because "T" refers to B-2's.) B-1 and B-2 both have "instance Show (IO a) where ...". Then you get some kind of overlapping instances error. B-1 and B-2 both contain C code, and both contain C extern functions of the same name (which is best practice) "fps_count" (real example from bytestring). Therefore, GHC cannot load both. (Neither can common linkers.) GHC panics in this case. Clearly, implementation-depend still suffers from 2 of these problems. As for cabal, it never considers multiple versions. Which I like. Just chop up the Gordian Knot. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] package dependencies should distinguish between API and implementation?
Alexander Kjeldaas gmail.com> writes: > 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. Yes. Does this hold in the example I mentioned? > I think the only dependency [ of template-haskell on containers ] > is in the implementation of PprMhttp://hackage.haskell.org/packages/archive/template-haskell/2.8.0.0/doc/html/Language-Haskell-TH-PprLib.html - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] package dependencies should distinguish between API and implementation?
On Mon, Feb 25, 2013 at 12:50 PM, Johannes Waldmann < waldm...@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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] package dependencies should distinguish between API and implementation?
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
