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
