Depending on hint/ghc API fixes the binary version I can use
build-depend on hint-0.4.0.0 with GHC 7.6.3, I get
% cabal configure Resolving dependencies... cabal: Could not resolve dependencies: trying: pointcloudviewer-0.1.0 (user goal) trying: hint-0.4.0.0/installed-cf3... (dependency of pointcloudviewer-0.1.0) trying: ghc-7.6.3/installed-494... (dependency of hint-0.4.0.0/installed-cf3...) trying: bin-package-db-0.0.0.0/installed-608... (dependency of ghc-7.6.3/installed-494...) trying: GLUtil-0.7.4/installed-223... (dependency of pointcloudviewer-0.1.0) next goal: linear (dependency of GLUtil-0.7.4/installed-223...) rejecting: linear-1.6/installed-300... (conflict: bin-package-db => binary==0.5.1.1/installed-72e..., linear => binary==0.7.1.0/installed-a33...)
This fails because
linear uses a
binary > 0.5.1.1, but through my use of
hint which depends on
hint does not directly depend on
binary), I pull in a constraint
binary == 0.5.1.1.
I believe this is bad, because depending on the GHC API in any way fixes the binary version I can use, which immediately makes a range of newer libraries unavailable to my program.
Probably GHC should somehow hide the fact that binary is used inside, and let the rest of my program use whatever binary it likes.
I am aware that this might not be immediately easy, since the GHC API might expose some
binary types to my program that I could try use with my newer binary version, which of course would be illegal.
Maybe it is possible to implement such a check into actual typechecking, and let it pass if I don't actually use types from the old version with functions from the new library. I actually believe I have seen compiler errors in the past where two identical types where not unified because one was from a different version, so maybe infrastructure for this is already in place?