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

Deep record field replacement #7491

Closed
vicuna opened this issue Feb 22, 2017 · 1 comment
Closed

Deep record field replacement #7491

vicuna opened this issue Feb 22, 2017 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Feb 22, 2017

Original bug ID: 7491
Reporter: @gasche
Assigned to: @gasche
Status: resolved (set by @gasche on 2017-02-22T15:42:28Z)
Resolution: suspended
Priority: low
Severity: feature
Target version: undecided
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @yallop @hcarty

Bug description

Deep record field replacement extends the record-replacement construction { r with f1 = e1; f2 = e2 } to support nested field accesses { r with p1 = e1; p2 = e2 }, where the ps are field paths (f.g.h). For example

{ r with f.g = e1; f.h = e2; i = e3 }

Conflicting assignments should be rejected statically. Two paths p1, p2 are in conflict when one is a prefix of the other (in particular if they are equal).

There an uncertainty on whether there should be a specified evaluation order on the values; the implementation should probably be consistent with the behavior of the non-extended construction.

Additional information

This feature was proposed by Romain Bardou in

#291

with an unsatisfying implementation and some uncertainties about the specification. Alain Frisch pointed out that Lexifi's dialect used to have this extension, and that he would be interested in having it again. See the discussion in #291: the general feedback on the feature is positive, but it was pointed out that a robust implementation would require playing with the record-typechecking code, and is expected to be difficult.

@vicuna
Copy link
Author

vicuna commented Feb 22, 2017

Comment author: @gasche

Following the consensus in #291, I am marking this issue as "suspended", which means that it is not a priority but people that would be able to propose a satisfying implementation should feel free to ask to reopen it.

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