Johannes Waldmann | 25 Feb 12:50 2013
Picon

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,
(Continue reading)

Alexander Kjeldaas | 25 Feb 15:09 2013
Picon

Re: package dependencies should distinguish between API and implementation?




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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Johannes Waldmann | 25 Feb 15:46 2013
Picon

Re: package dependencies should distinguish between API and implementation?

Alexander Kjeldaas <alexander.kjeldaas <at> 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.
Albert Y. C. Lai | 27 Feb 04:05 2013
Picon

Re: 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.

Gmane