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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe