Build failure with GHC-9.6, mtl-2.3.1 but transformers-0.5 about lens HOT 12 CLOSED

Answer: There is nothing wrong with semigroupoids-6

#if HAS_FOLDABLE1_TRANSFORMERS
instance Traversable1 f => Traversable1 (IdentityT f) where
  traverse1 f = fmap IdentityT . traverse1 f . runIdentityT

instance Traversable1 f => Traversable1 (Backwards f) where
  traverse1 f = fmap Backwards . traverse1 f . forwards

instance Traversable1 f => Traversable1 (Lift f) where
  traverse1 f (Pure x)  = Pure <$> f x
  traverse1 f (Other y) = Other <$> traverse1 f y

instance Traversable1 f => Traversable1 (Reverse f) where
  traverse1 f = fmap Reverse . forwards . traverse1 (Backwards . f) . getReverse
#endif

We just don't have these compat instances anywhere.

But should we have them in e.g. transformers-compat? I don't know, this install plan is somewhat a corner case.

from lens.

I think it would make sense to add these to transformers-compat. Do you mind opening an issue on the transformers-compat side?

from lens.

Oh wait, I missed the fact that this is specifically about Traversable1, which is in a library that transformers-compat doesn't depend on. That definitely complicates things...

from lens.

@RyanGlScott I was thinking of adding foldable1-classes-compat dependency to transformers-compat.

Then the instances can be defined uniformly in semigroupoids.

from lens.

I'm a bit confused. foldable1-classes-compat doesn't provide Traversable1, right? (I might be missing some details of the plan you have in mind.)

from lens.

We don't define (non-orphan!) Traversable1 instances in semigroupoids because of missing Foldable1 instances.

from lens.

Ah, that is the part that I was missing! Indeed, that plan sounds reasonable.

from lens.

It doesn't work easily, on older GHCs (GHC-8.0 and older)

[__0] trying: transformers-compat-0.7.2 (user goal)
[__1] trying: foldable1-classes-compat-0.1 (dependency of transformers-compat)
[__2] next goal: bifunctor-classes-compat (dependency of
foldable1-classes-compat)
[__2] rejecting: bifunctor-classes-compat-0.1 (cyclic dependencies; conflict
set: bifunctor-classes-compat, foldable1-classes-compat, transformers-compat)

And the cycle is there due Data.Functor.Constant instances.

I'd propose to drop transformers(-compat) dependency from bifunctor-classes-compat, and move Constant (a somewhat useless type) instances to transformers-compat. i.e. changing the dependency graph into

bifunctor-classes-compat <- foldable1-classes-compat <- transformers-compat

from lens.

A short term solution for this particular problem is to make lens require new enough transformers on GHC-9.6

i.e.

if impl(ghc >=9.6)
  build-depends: transformers >=0.6.1

That cannot be done in a revision though, unfortunately.

In practice that shouldn't affect anyone. Only weirdos (like myself) downgrade transformers.

EDIT: we could add revisions to already released lens disallowing the GHC-9.6 build plans. At this point the 5.2.1 is the only one, AFAICT.

from lens.

Urgh, good catch. Would this mean that we would also have to remove foldable1-classes-compat's dependency on transformers-compat?

from lens.

Would this mean that we would also have to remove foldable1-classes-compat's dependency on transformers-compat?

Yeah. Now I think it's quite heavy change to go through. Easier to just require newer transformers on GHC-9,6 (as in #1028 (comment)) if Foldable1 Reverse etc. instance is needed. In fact that's probably something that can be done already in semigroupoids.

EDIT: Note, there is precedence for this already. In some packages we use similar approach of requring at least some transformers version since some GHC/base like in https://github.com/recursion-schemes/recursion-schemes/blob/3114d863197c33467c1f0d339a9c67b4ffd16e0e/recursion-schemes.cabal#L65-L72 to make our lifes a bit easier.

from lens.

I have uploaded semigroupoids-6.0.0.1 to Hackage and blacklisted semigroupoids-6. I believe that should take care of this issue, but please re-open the issue if I have forgotten something.

from lens.