On 22 January 2015 at 10:37, Herbert Valerio Riedel <hvrie...@gmail.com> wrote: > 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).
Yes, if I didn't miss any other relevant issue. It's possible that we will need some coercion between Strict State that comes with GHC and one that is in transformers. > 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. >From a distro-developer perspective (gentoo) the only relevant library is ghc library, and ghc-bin is an executable, so in the worst case user will end up with having 2 different transformers package. But there will be no transformers madness as no library pulls concrete version. > 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. I don't know about a Stackage but at least Gentoo allow to install additional version for packages that are shipped with ghc and ghc library do not depend on it, it also handles a case when versions are equal, and then installation is a noop. Thinking of haskeline user will have problems only in case if user's haskeline version is equal to shipped with GHC but depends on a different tf version. I think that in this case force installing will lead to some level of breakage, however all executables (ghc-bin) and new libraries will continue working. Workaround is to make a minor version bump in haskeline and this can be done purely on a distro-level. > 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. Great. I'll try to cleanup code, and prepare ghc-tf-instances today, test of the packages that depend on the ghc library in order to understand if ghc-tf-instances solution works and then send diff to a Phab. Every tips, suggestions, or reminders of things that I should check will be gladly accepter. > Cheers, > hvr -- Alexander _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
