Allow building with GHC 8.8 #380
Merged
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
This makes some tweaks to allow building `singletons` with GHC 8.8: * As mentioned in #357 (comment), some local definitions now require explicit type signatures to compile due to changes in kind generalization brought about in GHC 8.8. I've added a lengthy section in `CHANGES.md` about this. * In order to avoid more problems due to the aforementioned kind generalization changes, this patch introduces "the `id` hack" described in #357 (comment). This is carefully documented in `Note [The id hack; or, how singletons learned to stop worrying and avoid kind generalization]` in `Data.Singletons.Single`. As a consequence of all this, this patch fixes #357. * It turns out that `promoteMethod` was accidentally passing the wrong method name to `promoteLetDecRHS`, causing the generated type family to have different names in its header and equations on GHC HEAD. Fortunately, this is easily fixed. * Due to [GHC Trac #16133](https://ghc.haskell.org/trac/ghc/ticket/16133) being fixed, `singletons`-generated code now requires explicitly enabling the `TypeApplications` extension. (The generated code was always using `TypeApplications` under the hood, but it's only now that GHC is detecting it.) Note that this does not yet drop compatibility with GHC 8.6 (I'll wait until a release candidate for 8.8 emerges), but this at least allows intrepid users to build `singletons` with 8.8 with fewer hassles.
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 makes some tweaks to allow building
singletonswith GHC 8.8:As mentioned in Can't build singletons on GHC HEAD post-"Remove decideKindGeneralisationPlan" #357 (comment), some local definitions now require explicit type signatures to compile due to changes in kind generalization brought about in GHC 8.8. I've added a lengthy section in
CHANGES.mdabout this.In order to avoid more problems due to the aforementioned kind generalization changes, this patch introduces "the
idhack" described in Can't build singletons on GHC HEAD post-"Remove decideKindGeneralisationPlan" #357 (comment). This is carefully documented inNote [The id hack; or, how singletons learned to stop worrying and avoid kind generalization]inData.Singletons.Single.As a consequence of all this, this patch fixes Can't build singletons on GHC HEAD post-"Remove decideKindGeneralisationPlan" #357 and addresses the second bullet point of GHC 8.8 checklist #356.
It turns out that
promoteMethodwas accidentally passing the wrong method name topromoteLetDecRHS, causing the generated type family to have different names in its header and equations on GHC HEAD. Fortunately, this is easily fixed.Due to GHC Trac #16133 being fixed,
singletons-generated code now requires explicitly enabling theTypeApplicationsextension. (The generated code was always usingTypeApplicationsunder the hood, but it's only now that GHC is detecting it.)Note that this does not yet drop compatibility with GHC 8.6 (I'll wait until a release candidate for 8.8 emerges), but this at least allows intrepid users to build
singletonswith 8.8 with fewer hassles.