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
In or-patterns, propagate path disambiguation from one prefixed constructor to other constructors #7386
Comments
Comment author: @gasche I realize now that another way to avoid this warning would be to not warn when type-directed disambiguation in fact selects a non-ambiguous candidate: this means that the syntactic ambiguity is in fact benign, as the types determine the only possible choice. That's a feature request for the ambiguity warning. |
Comment author: @alainfrisch
|
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. |
I still believe that "at the head of the same or-pattern" or "at the head of clauses" is a good criterion to propagate qualifying modules or do multi-label disambiguation, because it is simple, predictable, useful in several situations and consistent with what we do for record fields. I am putting "implementing this" on my medium-term TODO-list, please complain if you don't like the idea! |
I think this would be valuable. This is something to which I've seen newcomers have a sort of "silly type-checker is just being intentionally obtuse" reaction. It seems to be run into reasonably frequently, though we tend to react by putting a type annotation on |
I'm a little worried about it because I assume that: match e1, e2 with
| A, C -> ...
| M.B, D -> ... will work, but: match e2, e1 with
| C, A -> ...
| D, M.B -> ... won't |
With the simple criterion I proposed, neither would work, because they are not at the "head" of the pattern. Any extension that goes under constructor may run into trouble (in theory "at the same position under the same constructors" should work, but in fact because of GADTs it would only be correct in general to take the first argument of the constructor, giving the feeling of arbitrariness that Leo demonstrates in his example). |
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. |
Original bug ID: 7386
Reporter: @gasche
Status: acknowledged (set by @xavierleroy on 2017-02-23T16:06:20Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.03.0
Category: typing
Related to: #5759 #5980 #7443
Child of: #6951 #7409
Monitored by: @ygrek @jmeber @yallop @hcarty
Bug description
If we write a record pattern or expression with fields { a; M.b; c }, it is understood as equivalent to { M.a; M.b; M.c }. I would like this property to also hold of variant constructors appear in an or-pattern (or at the head of a list of clauses): (A | M.B | C) should be equivalent to (M.A | M.B | M.C), and
equivalent to
Additional information
Here is a concrete example I just had of a situation where this feature would be useful to me:
This is code is from https://github.com/Engil/Canopy . When compiled from 4.03, it raises the following warnings:
The best way I see to silence the warning is to write
but I would find it natural if it was possible to prefix only the first constructor.
We previously discussed this feature during the type-based-constructor/field-disambiguation debate, but the applicability scope I had in mind was too broad and with an unclear specification. I believe that "are in a single or-pattern" (or, as a generalization, at the head of the clauses of a matching) is a clear, simple and useful specification.
The text was updated successfully, but these errors were encountered: