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

Extensible record types #7534

Closed
vicuna opened this issue May 18, 2017 · 7 comments
Closed

Extensible record types #7534

vicuna opened this issue May 18, 2017 · 7 comments

Comments

@vicuna
Copy link

vicuna commented May 18, 2017

Original bug ID: 7534
Reporter: @alainfrisch
Status: acknowledged (set by @xavierleroy on 2017-09-30T16:14:03Z)
Resolution: open
Priority: normal
Severity: feature
Category: language features
Monitored by: @nojb runhang @ygrek @yallop

Bug description

We already have extensible sum types. What about adding extensible record types? This might be very useful to represent "property bags" in an efficient way.

This could look like:

  type t = { .. }
  type t += { x: int = 0 }
  let x : t = { }
  let y : t = { x = 42 }
  let f (r : t) = r.x
  let g (r : t) = {r with x = 42}
  let h : r -> int = function {x; _} -> x

  module M : sig type t += {x: int} end = struct type t += { x: int = 0 } end
  module N : sig type t += {x: string} end = struct type t += { x: string = "" } end
  let r = {M.x = 42; N.x = "hello"}

On the implementation side:

  • Each extension label could be represented as a block with Object_tag (as for extension constructors), also holding the default value.

  • An extensible record value could be represented roughly as an object where the index of fields in the "vtable" would not be obtained by hashing the name, but using directly the unique integer stored in the extension label block. We would reuse the existing machinery for caching lookups.

@vicuna
Copy link
Author

vicuna commented May 18, 2017

Comment author: @lpw25

Since you bring it up I had a design for this lying around in some notes somewhere. It follows pretty closely with what you suggest (even using the same syntax). The main difference was that it was mixed with a notion "optional label", so in addition to the "default argument" style of your proposal:

type t += { x: int = 0 }
r.x
function {x; _} -> x

it also supported:

type t += { ?y: int }
r.?y
function {?y; _} -> y

with

r.y

as short-hand for:

(let { ?y = Some y' } = r in y')

(including the ensuing warning -- I include it for syntactic consistency rather than usefulness)

and

function {y; _} -> y

as shorthand for:

function {?y = Some y} -> y

@vicuna
Copy link
Author

vicuna commented Sep 30, 2017

Comment author: @xavierleroy

You will need very convincing use cases to justify the implementation complexity for this extension.

@vicuna
Copy link
Author

vicuna commented Mar 6, 2018

Comment author: @alainfrisch

A typical use case would be an extensible application that can be extended with addins, where addins would need to attach custom data to objects in the application and retrieve the data later. This could be implemented using a technique such as the one you described in http://caml.inria.fr/pub/ml-archives/caml-list/2001/05/670222a47a96487f236602e00781f497.en.html but would seem much more idiomatic (and could be made much more efficient) with some language-level support.

A concrete example would be a compiler where optimization passes could be loaded dynamically; some passes could store custom data on each AST node and other passes, later in the compilation process, could react on such data.

FWIW, we have much more uses for such "property lists" (currently using a library) than for extensible sum types in our code base.

@vicuna
Copy link
Author

vicuna commented Mar 7, 2018

Comment author: @lpw25

I would say that at least 50% of the (non-exception) uses of extensible variants I've seen are really emulating extensible records. They usually use a hash table combined with an extensible GADT for the key -- which needs to be both used as the key and stored in the result.

Of course, uses of extensible variants are pretty rare, so I'm not sure how convincing these examples are, but there is at least some use for this feature in the wild.

@github-actions
Copy link

github-actions bot commented May 8, 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 8, 2020
@Drup
Copy link
Contributor

Drup commented May 8, 2020

Such feature will only happen if someone with a solid design and intention to implement it shows up. At this point, it should probably go through the RFC process. In the meantime, I don't think it's necessary to keep this open.

@xavierleroy
Copy link
Contributor

RFC material, indeed.

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

3 participants