New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Odd behaviour of refutation cases with polymorphic variants #7520
Comments
Comment author: @lpw25 This seems to be a regression between 4.03.0 and 4.04.0. |
Comment author: @garrigue OK, the situation is rather complicated. The natural fix here would be to reconstruct the type annotation to the wild card, which is available in the typed tree but discarded in the translation (it cannot occur for generated patterns). But this requires writing a new translation to parsetree types. It might be possible to use Untypeast.typ, but I'm concerned that the scoping might be wrong... or is it really ok? By the way, the behavior when adding an extra refutation is strange. The type inferred seems wrong anyway. |
Comment author: @garrigue Actually, I understand what's happening in the last case: pressure_variants is called with all the cases (including the refutations), and assumes that this is an open variant type, which later by unification makes it a fixed one. BTW, in what kind of code does this pattern arise? |
Comment author: @garrigue Tentative fix at #1328, using Untypeast. Note that I didn't fix the second problem (with an extra refutation case), because removing refutation cases breaks the logic of pressure_variants. It seems better to assume that adding an extra refutation cases implies a real intent wrt. the inferred type. |
Comment author: @xavierleroy Tentative fix didn't work. Pushing this for after 4.06. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Is this issue made any easier to fix by the various changes to typing pattern matching? Personally, I still think that the general approach of generating actual Parsetree fragments and re-typechecking them is a mistake that is destined to always cause issues like this one. Is there a particular reason that we don't have a separate data type to represent the candidate patterns (with things like type annotations and constructor identifiers already resolved) and a separate function for check that these candidate patterns are well typed? |
For me this rather falls in the category: combination of GADT and polymorphic variant is unsupported. |
Looking back at #7269, which is the source of the If I remove |
⸮ |
I should have add: for me. |
Original bug ID: 7520
Reporter: @lpw25
Status: acknowledged (set by @xavierleroy on 2017-09-30T09:08:45Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.04.0
Target version: later
Category: typing
Monitored by: @gasche @yallop
Bug description
Refutation cases have some odd behaviour with polymorphic variants. Given an uninhabited type:
The following fails:
It continues to fail if the variant type is constrained:
But it works of the type is fixed:
Or if we add a second empty refutation case:
The text was updated successfully, but these errors were encountered: