-
Notifications
You must be signed in to change notification settings - Fork 3
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
Bugfix in th-expand-syns-0.4.9.0
breaks th-reify-many
#9
Comments
This was referenced Aug 30, 2021
I revised all the releases of |
mgsloan
pushed a commit
that referenced
this issue
Sep 6, 2021
Fix released in |
mgsloan
added a commit
to mgsloan/stackage
that referenced
this issue
Sep 6, 2021
Issue fixed in version 0.1.10 of th-reify-many (see mgsloan/th-reify-many#9)
Also, I've added you as a collaborator on github and maintainer on hackage, which will expedite such fixes if they occur again in the future :) |
Thanks, @mgsloan! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After uploading
th-expand-syns-0.4.9.0
, I noticed thatth-orphans-0.13.11
now fails to compile:Some investigation reveals that a minor bugfix in
th-expand-syns-0.4.9.0
is affecting the behavior ofth-reify-many
, which has adverse consequences for libraries that depend on it (e.g.,th-orphans
). Here is a test program which illustrates the difference betweenth-expand-syns-0.4.8.0
and0.4.9.0
:With
th-expand-syns-0.4.9.0
, this will print out the following output, as expected:But on
th-expand-syns-0.4.8.0
, this will instead print out the following output:Notice that the kind signature has been pushed inwards.
What does any of this have to do with
th-reify-many
? It turns out thatth-reify-many
was silently relying on the buggy behavior ofth-expand-syns-0.4.8.0
in order to work correctly in some cases. When you callreify
on a class name (asth-expand-syns
does here), it will reify some instance arguments with an outermost kind signature. For example, if we use theLift
example from earlier, we get:When checking if an instance has already been defined,
th-reify-many
will attempt to strip off these kind signatures (using theunSigT
function) so as not to affect the results of(==)
. This happens in this line:th-reify-many/src/Language/Haskell/TH/ReifyMany/Internal.hs
Line 103 in a992106
However, note that
unSigT
is called on the head of the application (i.e., the result ofheadMay
), not on the overall application itself. In other words, this will remove the kind signature in(Maybe :: *) a
, but it will not remove the kind signature in(Maybe a) :: *
. Because of this, the call tounAppsT
will not decompose the(Maybe a) :: *
application, which causesth-reify-many
to incorrectly believe that aLift
instance does not exist forMaybe
.One possible fix is to just call
unSigT
an additional time:This is sufficient to make
th-orphans-0.13.11
compile again.The text was updated successfully, but these errors were encountered: