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

access to row variables #6952

Closed
vicuna opened this issue Aug 4, 2015 · 1 comment
Closed

access to row variables #6952

vicuna opened this issue Aug 4, 2015 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Aug 4, 2015

Original bug ID: 6952
Reporter: @c-cube
Status: acknowledged (set by @damiendoligez on 2015-11-27T14:51:25Z)
Resolution: open
Priority: normal
Severity: feature
Category: typing
Monitored by: @thizanne @Drup @diml @yallop @hcarty

Bug description

I hope this is not a duplicate of some old question or ML thread on the same topic. I apologize if it is the case. I am not a type theory expert, so the question might be stupid.

As far as I know, OCaml uses row variables internally to support inference on objects and polymorphic variants. However, this is hidden from the user (except for the object type notation <a: t; b: u; ..>).

I think several people would very much like to have access to this row variable with a type variable, both for objects and poly variants, as in (roughly):

val hide_foo : <foo: 'a; .. as 'r> -> < 'r >
val hide_foo' : [`Foo | .. as 'r] -> [>'r]

My guess is that 'r would not be a regular type variable, which would require a kind system or something similar?

Furthermore, if row variables were actually first-class, I think it would be very interesting to have "extensible tuples", such as 1, "foo", .. of type int * string * .. as 'r. If it were the case, some functions could be generalized, such as fst : 'a * .. -> 'a, snd : 'a * 'b * .. -> 'b, map_fst : ('a -> 'b) -> 'a * .. as 'r -> 'b * 'r, etc.

@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

1 participant