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
Comments
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 } it also supported: type t += { ?y: int } 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 |
Comment author: @xavierleroy You will need very convincing use cases to justify the implementation complexity for this extension. |
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. |
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. |
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. |
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. |
RFC material, indeed. |
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:
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.
The text was updated successfully, but these errors were encountered: