2008/10/14 Thomas Schilling <[EMAIL PROTECTED]>: > How does this help? The problem is that a compiler plugin (which is > effectively a GHC API client) might see two different versions of > binary and would have to choose the one bundled with GHC.
Right. Basically, we /have/ to expose Binary because: 1) Users will want to make instances of it so they can include their own data types in annotations 2) We really want to mention the Binary constraint in the GHC API in any event So the "private dependency" model doesn't apply in this case (and if we depend on binary, transitively bytestring will no longer be a private dependency since it is mentioned in the interface of binary). So there is no good solution to the problem that I know of... Simon M suggested that dynamic linking ameliorates the problem to some extent since you are then free to make (minor, bug-fixy) upgrades to the version of e.g. Binary that GHC uses without needing to recompile it. Though this is not a complete solution to the problem, it is certainly something to bear in mind. Cheers, Max _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
