On 2015-01-21 at 17:19:42 +0100, Alexander V Vershilov wrote:
I thought about providing package ghc-transformers-instances, that will provide instances for transformers's type classes for user. So ghc-tf-instances will depend on current ghc, and current transformers that could be provided by user environment.
So the price is seems to be mostly to tolerate orphan instances (and potentially having to copy more code from transformers into ghc, if one wants to use more features in ghc's code). One would have to make sure to keep that package updated everytime a new transformers or ghc package version is released, as well as making sure to always test all supported combinations of ghc/transformers versions before making a new releases. One thing to keep in mind though is that then 'haskeline' (which is needed by GHCi) still remains a consumer of 'transformers', so we'd still have to bundle a 'transformers' package version with GHC even if `ghc` doesn't depend on it anymore. Somewhat related, the `ghc` -> `Cabal` dependency was broken up in GHC 7.10 but we'll still bundle `Cabal` with GHC 7.10. I'm not sure how much this helps Stackage which I assume would constraint transformers to a single version, and therefore force a reinstall of the haskeline version shipped with GHC with a different version of transformers. Fwiw, I welcome decoupling libraries from the GHC distribution as every exposed library adds to the synchronisation-with-upstream-overhead when preparing new GHC releases, in addition to adding implicit version constraints to the package database. With a GHC release-management hat on though: As for GHC 7.10.1, it's rather late... at the very least it needs to get into RC2 (whose cut off is tomorrow) for that to happen. Cheers, hvr