Open nmeum opened 1 month ago
@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.]
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.
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/
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.
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
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oh, as proposed in https://github.com/lexi-lambda/freer-simple/pull/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.
Fixed by another revision. Must have made a mistake when testing. @nmeum Yeah, I think it is better if you take over.
This change was proposed upstream last year: https://github.com/lexi-lambda/freer-simple/pull/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.