So, I've been thinking. How do plugins get used by GHC? Maybe it's possible to have a ghc-plugin-api package that exports binary and ghc. IIUC, the plugin need not be part of the compiled program, so we could expose binary only to the plugins. This way at least only plugin-writers would be bound to GHC's version of binary.
2008/10/14 Max Bolingbroke <[EMAIL PROTECTED]>: > 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
