Skip to content
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

Covariance propagation across functors #7212

Open
vicuna opened this issue Apr 5, 2016 · 8 comments
Open

Covariance propagation across functors #7212

vicuna opened this issue Apr 5, 2016 · 8 comments

Comments

@vicuna
Copy link

vicuna commented Apr 5, 2016

Original bug ID: 7212
Reporter: @Drup
Assigned to: @garrigue
Status: acknowledged (set by @damiendoligez on 2016-04-05T14:20:18Z)
Resolution: open
Priority: normal
Severity: feature
Target version: later
Category: typing
Related to: #5984
Monitored by: @Drup

Bug description

In the attached file, one can see that covariance doesn't seem propagated across type aliases with functors. The behavior leads to rather surprising behaviors.

This appeared in a "real" situation in tyxml where we have a wrapping interface that is sometimes instantiated with covariant types:

With stable tyxml:
# #require "tyxml" ;;
# Html5.M.Xml.W.nil () ;;
- : '_a list = []

Maybe related (thanks yallop): #5984

File attachments

@github-actions
Copy link

github-actions bot commented May 9, 2020

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.

@github-actions github-actions bot added the Stale label May 9, 2020
@garrigue
Copy link
Contributor

garrigue commented May 9, 2020

That is a long standing issue. It would help if somebody could document where it hurts.

@garrigue garrigue removed the Stale label May 9, 2020
@Drup
Copy link
Contributor

Drup commented May 9, 2020

Well, as tyxml demonstrate, everytime you have something parametrized by a notion of collection that is instantiated (many collections are covariant, but not all), and you use it through the abstract API.

I suspect this will hurt even more with modular (explicit|implicits) ....

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 12, 2021
@Octachron Octachron removed the Stale label May 12, 2021
@gasche
Copy link
Member

gasche commented May 12, 2021

My understanding is that fixing this would require re-computing the properties (variance, etc.) of type declarations when they are changed by a substitution. I don't understand if this would have a negative performance impact; in theory this is a fixpoint, in practice we can start from the previously-computed properties so in the common case (no change) a single iteration should be enough. I also don't know if this is very difficult to implement (it is probably easier now that we are working on better signature-item grouping logic, see #10401), or just nobody has been able to put the effort of pulling this important change and evaluating it.

In general for type properties there are two schools:

  • the type property should be computed at type-declaration time, stored in the signature
  • the type property should be computed on-demand at property-checking time, by performing possibly-arbitrary expansions

Note that the present issue only affects declaration-time properties, not on-demand properties (that are recomputed anew on functor instances, where expansions "see" the functor argument), and that has been used as an argument to switch property computation to the on-demand style rather than declaration-time style (see #10017, #10041). I would be interested to know if this limitation of the declaration-time approach can be fixed, because it influences the design/implementation of all type properties.

(For some properties the on-demand style is obviously fine performance-wise, because checking is very rare. This is typically the case of immediacy, which is thus a good candidate for on-demand mode. But for variance it's not clear that we would like to perform computations on each subtyping coercion. (Or, for unboxed constructors, on each compilation of the constructor used as a pattern.) So maybe the on-demand style should consider caching seriously, possibly by caching the result in the type declaration itself. But caching is only possible if the property is formulated in a parametrization-friendly way, so that we can compute the property of parametrized types parametrized over the property of its type parameters.)

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 16, 2022
@garrigue garrigue removed the Stale label May 16, 2022
@garrigue
Copy link
Contributor

Long standing problem

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 19, 2023
@garrigue garrigue reopened this Jun 27, 2023
@Octachron Octachron removed the Stale label Jan 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants