-
Notifications
You must be signed in to change notification settings - Fork 37
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
Quantifying class methods' kind variables using TypeAbstractions
is fragile when higher-order kinds are involved
#605
Comments
I'm not sure that I want to fully revert #596, however. Besides quantifying promoted class methods' kind variables using - type M2Sym0 :: forall a b. (~>) a ((~>) b Bool)
+ type M2Sym0 :: forall (a :: Type) (b :: Type). (~>) a ((~>) b Bool) This is very desirable, especially given that it would allow us to fix #604 by simply giving classes like |
The changes in #596 cause `singletons-th` to use `TypeAbstractions` to explicitly quantify the kind variables of promoted class methods whenever the parent class has a standalone kind signature, thereby ensuring that the order of kind variables matches the order in which the user wrote them. At least, that was the intention. Unfortunately, as #605 reveals, this approach sometimes causes `singletons-th` to generate ill-kinded code for promoted class methods, and there isn't an obvious way to work around this limitation. As such, this patch reverts the `TypeAbstractions`-related changes from #596. Once again, `singletons-th` now does not make any guarantees about the order of kind variables for promoted class methods or their defunctionalization symbols. On the other hand, this patch _does_ keep the changes from #596 that cause `singletons-th` to propagate kind information from the parent class's standalone kind signature through to the promoted class methods' defunctionalization symbols, as this feature is useful independent of the `TypeAbstractions`-related changes. I have taken the opportunity to document why we do this in the new `Note [Propagating kind information from class standalone kind signatures]` in `D.S.TH.Promote`. I've removed the `T589` test case, as the functionality it was testing no longer exists after reverting the `TypeAbstractions`-related changes. I have also added a new `T605` test case that ensures that the regression from #605 stays fixed. In a subsequent commit, I will add another test case that demonstrates that the kind propagation works as intended. Fixes #605.
While writing a fix for #604, I attempted to give
Traversable
a standalone kind signature, only forsingletons-th
to generate code that failed to kind-check. Here is a minimized example of the problem:This will generate the following code:
Which causes GHC to error thusly:
To see what the problem is, look more closely at the definition of
Traverse'
:Note that the
@f_abhJ
binder does not have an explicit kind signature. When I introduced the ability for promoted class methods to bind their kind variables usingTypeAbstractions
(in #596), I had assumed that GHC would be able to infer thatf_abhJ :: Type -> Type
. The reality is much more dire, however: becausef_abhJ
lacks an explicit kind signature, GHC assumes thatf_abhJ :: Type
! As a result, there is a kind mismatch.I'd like to blame GHC here, but I'm not sure that I could even call this behavior a GHC bug. GHC has a convention that when you write
type family T a
(without any other kind information), then GHC will defaulta
's kind toType
. As such, if you write:Then it seems consistent for GHC to default
a
's kind toType
as well. Similarly if you wroteT @a c
.This is a perfectly consistent design on GHC's end, but one that is very inconvenient for
singletons
's needs. The only way to repair this would be to annotatef_abhJ
with an explicitType -> Type
kind signature, but this would require some cleverness in order to infer. In general, you'd likely need full-blown kind inference in order to do this well, and I am very reluctant to go down that path. Nor can we write something like(f_abhJ :: _)
and leverage GHC's kind inference, since GHC doesn't allow writing wildcard types in type family declarations.Unfortunately, I think this means that the proposal in #589 is simply not viable with the current state of GHC. I propose to revert #596, especially given that this is a blocker for fixing #604.
The text was updated successfully, but these errors were encountered: