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

Infer variance for GADTs without equality #7494

Closed
vicuna opened this issue Feb 24, 2017 · 6 comments
Closed

Infer variance for GADTs without equality #7494

vicuna opened this issue Feb 24, 2017 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Feb 24, 2017

Original bug ID: 7494
Reporter: @yallop
Assigned to: @garrigue
Status: assigned (set by @yallop on 2017-02-24T14:28:33Z)
Resolution: open
Priority: normal
Severity: feature
Category: typing
Related to: #5688 #7004
Monitored by: @gasche

Bug description

The current approach to variance for GADT-style definitions is overly conservative.

For example, the following program is currently accepted:

type 'a t = T of 'a
type +'a s = 'a t

but the following program, which ought to be equivalent, is rejected:

type 'a t = T : 'a -> 'a t
type +'a s = 'a t

The second program can be fixed by adding a variance annotation to 't' -- i.e., variance for GADT-style definitions is checked, but not inferred.

It would be safe, consistent, and convenient to infer variance for parameters of GADT-style definitions that don't partake in any equalities (i.e. that are not refined in the return types of constructors).

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @gasche

I thought I'd add a reference to my work on variance of GADTs, that discusses whether it is possible to also infer variances for variables that do participate in GADT equations (in short: yes, but it requires making assumptions on the language that are true today but would not necessarily be preserved by new typing features):

GADTs meet subtyping
Gabriel Scherer, Didier Rémy, 2013
https://arxiv.org/abs/1301.2903

@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

This issue seems to be about something much simpler: currently, a variant type is consider to be a GADT as soon as one of its constructors is given with an explicit return type. But this syntax can also be used for normal constructors (involving no equation). It would be better to have a semantic criterion.
This said, the syntactic criterion also has advantages, as changes In behaviour are immediately visible from the syntax.

@gasche
Copy link
Member

gasche commented May 9, 2020

Well I assume that @yallop would also be interested in constructors that do contain existential types, or add equality constraints on some other type parameters. The point is to ask whether the non-guarded parameters could have their variance inferred.

@trefis trefis removed the Stale label May 11, 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.

@github-actions github-actions bot added the Stale label May 14, 2021
@gasche gasche removed the Stale label Jun 16, 2021
@gasche gasche reopened this Jun 16, 2021
@github-actions
Copy link

github-actions bot commented Jul 1, 2022

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 Jul 1, 2022
@github-actions github-actions bot closed this as completed Aug 1, 2022
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

4 participants