is there any downside using a human readable Read/Show instance for the ghc package database serialization piece? adding parsec to the baked into ghc core would have pretty strong implications on which versions of other packages (where applicable) can be built with ghc... *Zooming out a teeny bit*... wasn't there some recent discussion on making it easier to have ghc coherently cope with multiple versions of a library being installed? I feel like this parsec inclusion would be a lot *less* contentious once thats been done, because then the ghc usage of the parsec library could be private / hidden from end users (possibly?) cheers -Carter On Sun, Mar 17, 2013 at 4:20 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
On Sun, Mar 17, 2013 at 09:04:58PM +0100, Henning Thielemann wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human
readable format. The only place I can think of it being used is in the package database, but we could use either Read/Show for that, or just exclusively use the binary format.
I already needed the human readable format in order to check what information a custom configure file generated.
You can use "ghc-pkg describe p" for that.
I don't think you should ever need the human readable format unless you need to alter the package database by hand.
I think I also altered these package descriptions in order to check what the correct content should be.
______________________________**_________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/**mailman/listinfo/ghc-devshttp://www.haskell.org/mailman/listinfo/ghc-devs