Proposal for removing transformers dependency

Herbert Valerio Riedel hvriedel at gmail.com
Thu Jan 22 07:37:25 UTC 2015


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


More information about the ghc-devs mailing list