New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
interpretM sometimes needs extra constraints #6
Comments
I have pushed a fix for this problem, and I plan on releasing a new version with the fix shortly. However, I will note that it does not make your program work as-written, since removing the
I’m not entirely sure why this happens, since it’s unclear to me why the local constraint It can be solved by adding a type annotation: runFx :: forall effs a
. ( LastMember IO effs )
=> Eff (Fx2 ': Fx1 ': effs) a
-> Eff effs a
runFx
= interpretM (\Fx1 -> putStrLn "Fx1")
. interpretM ((\Fx2 -> putStrLn "Fx2") :: Fx2 ~> IO) …or with explicit type application: runFx :: forall effs a
. ( LastMember IO effs )
=> Eff (Fx2 ': Fx1 ': effs) a
-> Eff effs a
runFx
= interpretM (\Fx1 -> putStrLn "Fx1")
. interpretM @_ @IO (\Fx2 -> putStrLn "Fx2") I may look into the actual reason for this secondary problem, but it seems separate, and it might have more to due with GHC’s inference mechanism than this library. |
Thanks! Super strange - It definitely typechecks for me with the change I mentioned. Holler at me if you want any extra details for any reason. |
I can’t reproduce your behavior, even on GHC 8.2.1 with your set of extensions. Perhaps you can set up a self-contained |
I'll have a go in a few hours. |
Many thanks! |
So compositions of
interpretM
seem to have trouble carrying throughLastMember
constraints, somehow. This is the smallest example I could construct that reproduces.Removing the marked line works around the problem.
The text was updated successfully, but these errors were encountered: