On Mon, 2008-10-13 at 18:06 +0100, Max Bolingbroke wrote: > However, we need to choose a method for serialising annotations: our > preferred method for doing this is to make use of the Hackage "binary" > package (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary) > so annotations can make use of all the existing instances for the > Binary class, and we can avoid implementing our own serialization > library. However, doing so would, in our proposed scheme, require > making binary a part of the GHC distribution (and since binary depends > on bytestring, bytestring would become further entangled with GHC). > This means that it won't be possible to upgrade the binary package in > a sane way without installing a new GHC compiled against that new > package, though as a sweetner we would be able to implement "deriving > (Binary)".
It seems clear that using bytestring and binary is a sensible longer term plan. On the other hand I'm not convinced yet that we have arrived at the final api for the binary package. For one thing we need to spend some time integrating the ideas from the binary-strict package. With the right infrastructure I don't think that issue need delay us however. > What is your reaction to this proposal, in particular the > binary-package dependency issue I outline briefly above? This is an excellent opportunity to implement private build dependencies. That is if the ghc api package is not exporting the ByteString or Binary types then it really does not matter which version of the bytestring and binary packages it uses. The idea is that one declares those deps as private in the .cabal file and then Cabal asks ghc to check that they really are used privately, the types from those packages are not exported from the exposed modules of the package. eg: ghc.cabal: build-depends-private: bytestring, binary I'm not sure what the best way to do the enforcement / checking would be. Perhaps cabal should use ghc --show-iface on the exposed modules' .hi files to check that nothing from the private build depends are exported. I'm not sure what to do about instances though. Then the cabal-install dep planner would not have to enforce that the version of the private build dependency was the same as the version for all other packages. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
