freer-simple needs template-haskell constraint relaxed to work with GHC >=9.4

[nmeum]

This change was proposed upstream last year: lexi-lambda/freer-simple#44

Unfortunately, upstream has sadly been unresponsive for a while. However, aside from the template-haskell constraint, the package still works fine with newer version of GHC. I use freer-simple extensively in a Haskell project of mine (LibRISCV) and haven't noticed any issues with GHC version >=9.4 so far. Furthermore, the upstream test suite still passes with both GHC 9.4, GHC 9.6, and GHC 9.8 with the relaxed template-haskell constraint.

[andreasabel]

@nmeum : Since the original maintainer has become passive, would you consider taking over this package?
(A trustee intervention (hackage revision) would not change the fundamental situation here.)
[Cited repo had last commit in Jan 2022, can be considered dormant.]

[nmeum]

Unfortunately, I don't have the capacity to take over maintainership for freer-simple. For my own projects I will probably look into migrating to the free package in the long run, relaxing the constraint gives me (and other users of freer-simple) more time to consider such a change.

[andreasabel]

That's unfortunate, because even a "dependency bumper"-maintainer would be better than no (active) maintainer.

For now, I made the revision: https://hackage.haskell.org/package/freer-simple-1.2.1.2/revisions/

[phadej]

Build profile: -w ghc-9.10.1 -O1
In order, the following will be built (use -v for more details):
 - freer-simple-1.1.0.0 (lib) (configuration changed)
 - freer-simple-1.1.0.0 (exe:freer-examples) (first run)
Configuring library for freer-simple-1.1.0.0..
Preprocessing library for freer-simple-1.1.0.0..
Building library for freer-simple-1.1.0.0..
[ 4 of 14] Compiling Control.Monad.Freer.Internal ( src/Control/Monad/Freer/Internal.hs, /codetmp/fs/freer-simple-1.1.0.0/dist-newstyle/build/x86_64-linux/ghc-9.10.1/freer-simple-1.1.0.0/build/Control/Monad/Freer/Internal.o, /codetmp/fs/freer-simple-1.1.0.0/dist-newstyle/build/x86_64-linux/ghc-9.10.1/freer-simple-1.1.0.0/build/Control/Monad/Freer/Internal.dyn_o )
src/Control/Monad/Freer/Internal.hs:156:10: error: [GHC-39999]
    • Could not deduce ‘Applicative b’
        arising from the superclasses of an instance declaration
      from the context: (MonadBase b m, LastMember m effs)
        bound by the instance declaration
        at src/Control/Monad/Freer/Internal.hs:156:10-69
      Possible fix:
        add (Applicative b) to the context of the instance declaration
    • In the instance declaration for ‘MonadBase b (Eff effs)’
    |
156 | instance (MonadBase b m, LastMember m effs) => MonadBase b (Eff effs) where
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Control/Monad/Freer/Internal.hs:156:10: error: [GHC-39999]
    • Could not deduce ‘Monad b’
        arising from the superclasses of an instance declaration
      from the context: (MonadBase b m, LastMember m effs)
        bound by the instance declaration
        at src/Control/Monad/Freer/Internal.hs:156:10-69
      Possible fix:
        add (Monad b) to the context of the instance declaration
    • In the instance declaration for ‘MonadBase b (Eff effs)’
    |
156 | instance (MonadBase b m, LastMember m effs) => MonadBase b (Eff effs) where
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Error: cabal: Failed to build freer-simple-1.1.0.0 (which is required by
exe:freer-examples from freer-simple-1.1.0.0).

This looks like a bug in GHC, as

class (Applicative b, Applicative m, Monad b, Monad m)
      ⇒ MonadBase b m | m → b where

But I think for now it should be restricted back, none of freer-simple versions works with GHC-9.10.1 .

EDIT: freer-simple-1.2.1.2 fails with the same error.

[phadej]

It's not a GHC bug, it's expected. GHC-9.8 warned about it:

src/Control/Monad/Freer/Internal.hs:156:10: warning: [GHC-36038] [-Wloopy-superclass-solve]
    I am solving the constraint ‘Monad b’,
      arising from the superclasses of an instance declaration,
    in a way that might turn out to loop at runtime.
    Starting from GHC 9.10, this warning will turn into an error.
    See the user manual, § Undecidable instances and loopy superclasses.
    Suggested fix:
      Add the constraint ‘Monad b’ to the instance context,
      even though it seems logically implied by other constraints in the context.
    |
156 | instance (MonadBase b m, LastMember m effs) => MonadBase b (Eff effs) where
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[nmeum]

Oh, as proposed in lexi-lambda/freer-simple#44 I only wanted to widen the constraint to <2.22 but it seems it has been widened to <2.23 instead? I haven't tested this with GHC 9.10 only with GHC >=9.4 && GHC <=9.8.

Apologizes if that wasn't clear from the issue description.

[andreasabel]

Fixed by another revision. Must have made a mistake when testing.
@nmeum Yeah, I think it is better if you take over.