Closed RyanGlScott closed 5 months ago
I'm not sure that I want to fully revert #596, however. Besides quantifying promoted class methods' kind variables using TypeAbstractions
, #596 has the nice secondary property of propagating user-written kind information from class standalone kind signatures through to the promoted methods' defunctionalization symbols. For example, the changes in #596 caused the T412
test case to refine its generated code:
- 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 Traversable
, Alternative
, etc. standalone kind signatures. I would like to keep this part of #596 while reverting the TypeAbstractions
-specific parts.
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.