You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, singletons-th always attempts to generate instance signatures for singled instance methods, even if the original instance code lacks instance signatures. For instance, singletons-th will take this code:
Note that the original instance lacks an instance signature, but the singled instance includes one anway. In order to infer the instance signature for the singled instance, singletons-th will reify the type of the method (or, if that cannot be found, the singled version of the method) and manually apply a substitution from class variables to instance types. See this code.
This instance signature inference is quite involved, and what's more, it doesn't work in all cases:
This convention of inferring the instance signature dates all the way back to commit c9beec5. 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, that example was 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, I claim that instance signature inference no longer serves a useful purpose.
I propose that we remove the instance signature inference code, which would greatly simplify the overall process of singling instance declarations. (We can still single instance signatures if the user provides them, but there's no real benefit singletons-th inferring them if the user leaves them out.)
The text was updated successfully, but these errors were encountered:
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.
Currently,
singletons-th
always attempts to generate instance signatures for singled instance methods, even if the original instance code lacks instance signatures. For instance,singletons-th
will take this code:And single it to:
Note that the original instance lacks an instance signature, but the singled instance includes one anway. In order to infer the instance signature for the singled instance,
singletons-th
will reify the type of the method (or, if that cannot be found, the singled version of the method) and manually apply a substitution from class variables to instance types. See this code.This instance signature inference is quite involved, and what's more, it doesn't work in all cases:
ScopedTypeVariables
in class method RHS #581, we need type variables from class method defaults and instance methods to scope over their bodies. However, the approach thatsingletons-th
uses 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. (I don't have an example off-hand of this happening, as this relies on in-flight changes in a fix for Out-of-scope type variable when usingScopedTypeVariables
in class method RHS #581, but this is a real problem.)This convention of inferring the instance signature dates all the way back to commit c9beec5. 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, that example was 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, I claim that instance signature inference no longer serves a useful purpose.I propose that we remove the instance signature inference code, which would greatly simplify the overall process of singling instance declarations. (We can still single instance signatures if the user provides them, but there's no real benefit
singletons-th
inferring them if the user leaves them out.)The text was updated successfully, but these errors were encountered: