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
Forall behavior has changed since 0.6 #31
Comments
Gah. I still don't have a working Haskell environment, but unraveling the definitions a bit more by hand:
Meanwhile, So the problem is that And now I'm starting to worry whether you can even construct
|
Or perhaps this less complicated function, which was (with a different implementation) in the provisional rewrite after
|
@oerjan Could you elaborate a bit on how to use those functions? In general, wouldn't it be too restrictive if |
The following snippet used to type check with constraints 0.4.1.3 but now it doesn't as of 0.6:
With constraints >= 0.6, GHC complains
This is because
and if
m ~ ReaderT () n
, GHC can't deduce the constraints.In contrast with constraints == 0.4.1.3:
so if
m ~ ReaderT () n
, the constraints becomewhich are true.
In order to work around this issue, I have to change the constraints of
foo
to containReaderT ()
:Was this use-site change intentional? Could we somehow restore the previous behavior (in
constraints
orlifted-async
) without sacrificing the better definitions ofForall
andSkolem
etc?The text was updated successfully, but these errors were encountered: