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
Original bug ID: 7707 Reporter:@lpw25 Status: new Resolution: open Priority: normal Severity: minor Version: 4.06.0 Category: typing
Bug description
The [mcomp] function doesn't really consider the row variable in polymorphic variants. For example, the following doesn't type check:
# type ('a, 'b) eq = Refl : ('a, 'a) eq;;
type ('a, 'b) eq = Refl : ('a, 'a) eq
# let f : (< foo : 'a . [> `Foo] as 'a >, < foo : 'b . [> `Bar ] as 'b >) eq -> 'a = function _ -> .;;
Characters 92-93:
let f : (< foo : 'a . [> `Foo] as 'a >, < foo : 'b . [> `Bar ] as 'b >) eq -> 'a = function _ -> .;;
^
Error: This match case could not be refuted.
Here is an example of a value that would reach it: Refl
because [mcomp] does not notice the incompatibility between:
'a. [> `Foo] as 'a
and
'b. [> `Bar] as 'b
This is of course safe, since it is conservative to assume that all types are compatible. Still it would be nice if it handled these types more accurately.
At the moment [mcomp] will only consider two polymorphic variants incompatible if one of them is closed and does not contain a tag from the other. This doesn't take account of cases where the row variable is a non-aliasable constructor or a universal variable. Ideally [mcomp] would construct the rows necessary to make the variants compatible and would then compare those rows with the actual rows for compatibility.
The text was updated successfully, but these errors were encountered:
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.
How did you stumble into this example?
I agree that fixing it should not be difficult (basically, one can take the minimal instance of each polymorphic variant type, which amount to closing, and they should be compatible), but is the extra work justified.
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: 7707
Reporter: @lpw25
Status: new
Resolution: open
Priority: normal
Severity: minor
Version: 4.06.0
Category: typing
Bug description
The [mcomp] function doesn't really consider the row variable in polymorphic variants. For example, the following doesn't type check:
because [mcomp] does not notice the incompatibility between:
and
This is of course safe, since it is conservative to assume that all types are compatible. Still it would be nice if it handled these types more accurately.
At the moment [mcomp] will only consider two polymorphic variants incompatible if one of them is closed and does not contain a tag from the other. This doesn't take account of cases where the row variable is a non-aliasable constructor or a universal variable. Ideally [mcomp] would construct the rows necessary to make the variants compatible and would then compare those rows with the actual rows for compatibility.
The text was updated successfully, but these errors were encountered: