Proposal for removing transformers dependency

Edward Z. Yang ezyang at mit.edu
Thu Jan 22 06:26:12 UTC 2015


Don't worry, we've never given any promise about GHC API
stability across major versions (or minor versions, for that
matter.)

Edward

Excerpts from Alexander V Vershilov's message of 2015-01-21 22:16:11 -0800:
> 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 <kazu at iij.ad.jp> 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 at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> 


More information about the ghc-devs mailing list