transformers-0.5.6.x and GHC-8.8

[phadej]

• added Contravariant instances, which are guarded by #if MIN_VERSION_base(4,12,0)
  • Note, that GHC-8.6.3 ships with transformers-0.5.5.0
• added Control.Monad.Trans.Writer.CPS
  • I think we need to make a new mtl release to add corresponding module + Monad* instances! Ping @RyanGlScott @bgamari (note: mtl is GHC boot library!)
  • And contravariant would need new release adding instances for transformers-compat version of .CPS transformers.

[RyanGlScott]

I definitely agree that we should

• [ ] Backport Control.Monad.Trans.{RWS,Writer}.CPS

It might be convenient to do this at the same time as #40.

Other changes from transformers-0.5.6.* that we should backport:

• [ ] The MonadFix instance for ListT
• [ ] The generalized type signature for except in Control.Monad.Trans.Except

In regards to your other bullet points:

• contravariant-1.5 already backports all of the Contravariant instances added in recent versions of transformers (with the exception of the *.CPS variants, of course, but there's nothing that contravariant can do about that until a new transformers-compat release appears that backports these types).

  Furthermore, there is no released version of transformers that simultaneously (1) lacks Contravariant instances and (2) support GHC 8.6 or later, so we don't need to do anything about that on transformers-compat's side.

• Ultimately, the question of whether mtl's API should be extended or not is immaterial here, since mtl is an entirely separate library from transformers-compat. If mtl does change, we can update transformers-compat accordingly later.

[phadej]

MTL is boot lib; but I guess there are no time to do anything for GHC-8.8. Luckily only parsec&Cabal depends on it, so it’s easy to upgrade if someone would need new things

Sent from my iPhone

On 23 Mar 2019, at 21.58, Ryan Scott notifications@github.com wrote:

I definitely agree that we should

Backport Control.Monad.Trans.{RWS,Writer}.CPS It might be convenient to do this at the same time as #40.

Other changes from transformers-0.5.6.* that we should backport:

The MonadFix instance for ListT The generalized type signature for except in Control.Monad.Trans.Except In regards to your other bullet points:

contravariant-1.5 already backports all of the Contravariant instances added in recent versions of transformers (with the exception of the *.CPS variants, of course, but there's nothing that contravariant can do about that until a new transformers-compat release appears that backports these types).

Furthermore, there is no released version of transformers that simultaneously (1) lacks Contravariant instances and (2) support GHC 8.6 or later, so we don't need to do anything about that on transformers-compat's side.

Ultimately, the question of whether mtl's API should be extended or not is immaterial here, since mtl is an entirely separate library from transformers-compat. If mtl does change, we can update transformers-compat accordingly later.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[RyanGlScott]

42

[RyanGlScott]

One thought that just occurred to me: old versions of the writer-cps-transformers package also export modules named Control.Monad.Trans.{RWS,Writer}.CPS. Will this be a problem, since transformers-compat will also be using these module names?

[phadej]

Hmm. Good question. If writer-cps-transformers (and writer-cps-mtl) are proper compat packages, then maybe transformers-compat can be without CPS stuff. Compats would be unfortunately fragmented, but we’d avoid duplicate module problem.

Sent from my iPhone

On 24 Mar 2019, at 13.14, Ryan Scott notifications@github.com wrote:

One thought that just occurred to me: old versions of the writer-cps-transformers package also export modules named Control.Monad.Trans.{RWS,Writer}.CPS. Will this be a problem, since transformers-compat will also be using these module names?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[RyanGlScott]

My understanding is that writer-cps-transformers isn't a compatibility package in the conventional sense. writer-cps-transformers-0.5.6.0 exports nothing and simply incurs a transformers >= 0.5.6.0 dependency, so the latest version of writer-cps-transformers can't co-exist with older versions of transformers.

[phadej]

Yes, but if you do writer-cps-transformers >= 0.5.5.0, it will work? Not as nice as one wish, but good enough.

We could ask (and help) @minad to make proper compat as writer-cps-transformers-0.5.6.1 too.

Sent from my iPhone

On 24 Mar 2019, at 16.12, Ryan Scott notifications@github.com wrote:

My understanding is that writer-cps-transformers isn't a compatibility package in the conventional sense. writer-cps-transformers-0.5.6.0 exports nothing and simply incurs a transformers >= 0.5.6.0 dependency, so the latest version of writer-cps-transformers can't co-exist with older versions of transformers.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[minad]

@phadej writer-cps-transformers is intended as a compatibility package, and was planned as such when Ross moved the CPS stuff upstream. There are also other writer-cps-* packages for mtl etc. Could you just add writer-cps-transformers as dependency?

If there are issues with writer-cps-transformers to make it really compatible, help would be much appreciated. I have no experience in how this should be done properly.

[minad]

@phadej I can also give you maintainer rights if you want.

[RyanGlScott]

I don't have a strong opinion as to whether the home for these modules should be transformers-compat or writer-cps-transformers. If we do choose writer-cps-transformers, then we can include a mention of it in the transformers-compat README.

[RyanGlScott]

I've decided to simply leave out the .CPS stuff in #42 and defer that to writer-cps-transformers.