Support scoped type variables in class/instance declarations #591
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
RyanGlScott
force-pushed
the
T581
branch
2 times, most recently
from
cf64084
to
86ae6c3
Compare
Previously, `singletons-th` would always attempt to generate instance signatures for singled instance methods, even if the original instance code lacks instance signatures. To do so, `singletons-th` will infer an instance signature by reifying the type of the method (or, if that cannot be found, the singled version of the method) and manually applying a substitution from class variables to instance types. This process is quite involved, and what's more, it doesn't work in all cases: * As noted in #358, inferred instance signatures can sometimes be ill-kinded. * In order to support singling examples like the ones from #581, we need type variables from class method defaults and instance methods to scope over their bodies. However, the approach that `singletons-th` used to reify the method type for the singled code will sometimes reify _different_ type variables than the ones used in the promoted code, leading to disaster. This convention of inferring the instance signature dates all the way back to commit c9beec5, and it's unclear why this choice was made. At the time of writing #358, I was convinced that inferred instance signatures were necessary to support examples like the one in #358 (comment). However, this example is only problematic due to the use of an explicit kind annotation on a promoted `case` expression, and these explicit kind annotations were removed in the fix for #547. As such, this convention no longer serves a useful purpose. This patch removes the instance signature inference code, greatly simplifying the overall process of singling instance declarations. Fixes #590.
Although #573 added some support for promoting/singling uses of scoped type variables, it did not properly support scoped type variables in class or instance declarations due to an oversight. This patch aims to correct that oversight. The key tricks to making this work are: * When promoting class or instance methods, we explicitly quantify the type variables in the "helper" type family so that we can bind them on the left-hand sides of the promoted type family equations. * In addition, we take care to only bring the _scoped_ type variables into scope over the right-hand sides of the promoted type family equations. See the new `Note [Scoped type variables and class methods]` in `Data.Singletons.TH.Promote.Monad` for the full details. Fixes #581.
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.
Although #573 added some support for promoting/singling uses of scoped type variables, it did not properly support scoped type variables in class or instance declarations due to an oversight. This patch aims to correct that oversight.
The key tricks to making this work are:
See the new
Note [Scoped type variables and class methods]inData.Singletons.TH.Promote.Monadfor the full details.Fixes #581.