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

Variance information is not properly propagated through functor applications #5984

Open
vicuna opened this issue Apr 12, 2013 · 10 comments
Open

Comments

@vicuna
Copy link

vicuna commented Apr 12, 2013

Original bug ID: 5984
Reporter: @yallop
Assigned to: @garrigue
Status: confirmed (set by @garrigue on 2017-03-15T05:58:24Z)
Resolution: won't fix
Priority: normal
Severity: feature
Target version: later
Category: typing
Related to: #2696 #6492 #7212
Parent of: #5985 #7321
Monitored by: @lpw25

Bug description

Type constructors that pass transparently through functors lose certain variance information along the way. For example, the following program

   module F(S : sig type 'a t end) = S

   module N : sig type +'a t end = F(struct type 'a t = 'a list end) 

is rejected with this error:

   Error: Signature mismatch:
       Modules do not match:
         sig type 'a t = 'a list end
       is not included in
         sig type +'a t end
       Type declarations do not match:
         type 'a t = 'a list
       is not included in
         type +'a t
       Their variances do not agree.

However, despite this error, the type that results from the functor application is actually marked as covariant, as illustrated by the fact that the following program is accepted:

  module F(S : sig type 'a t end) = S

  module N = F(struct type 'a t = 'a list end) 

  let f (x : [`A] N.t) = (x :> [`A | `B] N.t)
@vicuna
Copy link
Author

vicuna commented Apr 13, 2013

Comment author: @garrigue

This is well-known, long standing problems with variance and functors.
Making the variance correct would require computing it anew after
each functor application, which seemed rather heavy at the time.

Do you have a concrete example where it created problems ?

@vicuna
Copy link
Author

vicuna commented Nov 23, 2015

Comment author: @xavierleroy

I interpret the absence of discussion in the last two years as a "won't fix" decision. Correct?

@vicuna
Copy link
Author

vicuna commented Nov 23, 2015

Comment author: @yallop

This isn't causing problems for me in practice, so I'm happy for it to be closed.

@vicuna
Copy link
Author

vicuna commented Nov 23, 2015

Comment author: @xavierleroy

Thanks, Jeremy. Marking as "won't fix".

@vicuna
Copy link
Author

vicuna commented Nov 23, 2015

Comment author: @garrigue

Just for the record: this is not a definitive "won't fix".
I put it in the same category as allowing refinement in non-local abstract types.
I.e. something that the language should do, but that is not easy with the current implementation.

@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 15, 2020
@garrigue
Copy link
Contributor

There is actually more and more pressure to do this, so I'm tempted of moving this PR from feature-wish to bug.
(BTW, refinement of non-local abstract types has been done...)

@github-actions github-actions bot removed the Stale label Jun 19, 2020
@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.

@garrigue
Copy link
Contributor

I keep it open, because this should be fixed eventually.

@garrigue garrigue reopened this Nov 23, 2021
@github-actions github-actions bot removed the Stale label Nov 24, 2021
@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.

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

2 participants