mad.one:
That's all good news; will this release of ByteString be used for GHC 6.8.3? I'm a little tired of linking everything against 0.9.0.1 just so I can use Yi (since GHC/the-GHC-API links against it). :)
Indeed; this is the biggest issue I have with bytestring right now as it's interfered with my work with hs-plugins/GHC-api, especially considering I think the new cabal and ghc 6.8.3 should fix or at least warn about the library-version-mismatch issues (from what I've heard.)
The only probable fix I can think of (other than doing compile-time hackery on both the C and haskell side to make symbol names differ across releases, which is fairly infeasible i'd think and would regardless kill portability since template-haskell is the only viable option on the haskell note,) is to factor out the usage of bytestring in the GHC-API, or just stick the source code to bytestring into the GHC source tree so it's not built as a package (so you wouldn't see it in, e.g. 'ghc-pkg describe ghc', although I would think the names would still show up in the symbol table, regardless.)
But whatever route you choose, I'm not sure of the ramifications in general and it seems to be a tough cookie to solve properly, so we don't end up breaking things as we try and fix them. Don probably has better ideas.
The use of bytestring inside GHC is limited only to a little bit in the GHCi modules -- and could easily be replaced, I suspect. Doing so would remove one dependency from GHC's core, as well as making it easier to upgrade bytestring versions. Ian, have you looked at this? -- Don