Partially revert #596, give PAlternative (and friends) the correct kinds
#606
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
In particular, make note of the circumstances under which issues like #604. There is no way for `singletons-th` to generate code that avoids the problems in #604 in all cases, so we instead advise users to be wary when promoting code involving classes that are parameterized over higher-kinded type variables (e.g., `Alternative`).
Previously, `singletons-th` would generalize the kinds of `PAlternative` and related classes (e.g., `PMonadPlus`), as well of the kinds of the defunctionalization symbols for various classes that are parameterized over a higher-kinded type variable. As described in the "Class constraints" section of the `README.md`, the recommended workaround for this issue is to give the classes in question explicit kinds, so this patch does just that by giving `Alternative`, `MonadPlus`, etc. standalone kind signatures. This causes the code in `singletons-base` to deviate a bit from the original code in the `base` library. I have written a new `Note [Using standalone kind signatures not present in the base library]` and cited it in all of the places where such a deviation occurs. Fixes #604.
RyanGlScott
added a commit
that referenced
this pull request
Jun 30, 2024
This adds more explicit `Type -> Type` kind signatures to definitions that would otherwise be kind-generalized to have overly polymorphic kinds: * The kinds of `Asum` and `Msum` (the promoted counterparts to the term-level `asum` and `msum` functions, respectively). * The helper type families generated when promoting the `Alternative` and `MonadPlus` instances for `Data.Functor.Product`. This sort of kind polymorphism isn't observable by users in today's GHC, but it will cause problems later in a future version of GHC that implements [GHC#23515](https://gitlab.haskell.org/ghc/ghc/-/issues/23515). (See #601.) (I should have added these as part of #606 or #607, but I forgot them due to an oversight.)
RyanGlScott
added a commit
that referenced
this pull request
Jul 1, 2024
This adds more explicit `Type -> Type` kind signatures to definitions that would otherwise be kind-generalized to have overly polymorphic kinds: * The kinds of `Asum` and `Msum` (the promoted counterparts to the term-level `asum` and `msum` functions, respectively). * The helper type families generated when promoting the `Alternative` and `MonadPlus` instances for `Data.Functor.Product`. This sort of kind polymorphism isn't observable by users in today's GHC, but it will cause problems later in a future version of GHC that implements [GHC#23515](https://gitlab.haskell.org/ghc/ghc/-/issues/23515). (See #601.) (I should have added these as part of #606 or #607, but I forgot them due to an oversight.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR consists of patches that:
TypeAbstractions-related changes in Quantify class methods' kind variables in the correct order usingTypeAbstractions#596 to fix the regression observed in Quantifying class methods' kind variables usingTypeAbstractionsis fragile when higher-order kinds are involved #605. This fixes Quantifying class methods' kind variables usingTypeAbstractionsis fragile when higher-order kinds are involved #605.PAlternativeand similar classes are parameterized over a variable of kindType -> Typerather thank -> Typeby giving them standalone kind signatures. This fixes Overly general kind forPAlternative#604.README.mdRefer to the individual commit messages for further details.