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

On 22 January 2015 at 09:34, Joachim Breitner wrote:

Hi,

Am Donnerstag, den 22.01.2015, 08:37 +0100 schrieb Herbert Valerio Riedel:

...

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.

although there has been talk about only shipping the .so file with a clash-free name or path... was this not done simply because noone bothered enough to actually do it, or was there a bigger problem?

There was an email thread about this very problem started by Michael Snoyman last month. As noted later in that thread, https://www.haskell.org/pipermail/ghc-devs/2014-December/007826.html the packages mentioned above and others were added to the ghc-pkg database in order to address https://ghc.haskell.org/trac/ghc/ticket/8919, hence making the problem worse. It sounds to me like Alexander's patch, plus the solution alluded by Joachim above for "invisible" packages that don't clash with ones registered in the ghc-pkg db, would allow us to avoid having any of the following packages leaking into all sandboxes for all users of GHC 7.10 and following: * haskeline * transformers * xhtml * terminfo Perhaps others. That would be a big win. Here's a more ambitious change: if we could make installation of the ghc library itself optional, then we could avoid forcing the installation of a whole swathe of other packages into the global db, including transformers. Best, Mathieu

On 22 January 2015 at 10:37, Herbert Valerio Riedel 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

Ok. In this case, I'm interested in main users of ghc library, as I have to make sure that they will not be broken by any changes that I'm introduce? I can take few from hackage but maybe there are ones that users care about. So I can validate my solution. -- Alexander On 22 January 2015 at 03:11, Kazu Yamamoto wrote:

Hi,

I also hope that this is integrated into GHC 7.10.

--Kazu

...

Hello.

I'm coming with a proposal for removing transformers dependency from ghc library. The reason for this proposal that it's not possible to build consistent environment where a modern libraries (that depend on a newer transformers or mtl-2.2) and libraries that use ghc API are used together. And often people are tend to use version that is bundled with ghc, even if newer are available.

As transformers usage are quite limited in ghc, and it's really relevant in ghc-bin, it's possible to duplicate the code, and provide required fixes in ghc-bin.cabal. As a result ghc uses it's own MonadIO, MonadControl and Strict State, and ghc-bin.cabal (ghc/*) uses ones from transformers.

I have prepared a proof of concept [1], however it doesn't look very clean and it's quite possible that will require some generalization, for example introduction of the ghc-transformers-instances package that will have all required instances.

Should I continue doing this? Are there any things to consider and fix?

[1] https://github.com/qnikst/ghc/compare/wip/remove-tf -- Alexander

---

ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Alexander