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
Proposal: make Pervasives.ref abstract type #6994
Comments
Comment author: @alainfrisch A possible direction would be to keep more information in the lambda code: record literals and field updates/access could be identified as such (with an indication of the type definition). |
Comment author: @bobzhang @Frish would you elaborate your solution? My original proposal is quite easy to implement. Thinking twice, I think a more general solution (without breaking existing code) is even better
for example type t = { x : int } let f u = u.x -> instead of (Pfield 0 x) --> (Pgetonlyfield x)
type 'a option = None | Some of 'a This solution is definitely much better than my original proposal, but it depends on how much resources you have. What do you think? |
Comment author: @alainfrisch
I was thinking about keeping the reference to the type declaration in the lambda representation. As in: (Precordfield 0 r d) with d of type Types.type_declaration. But this is a real departure of the current philosophy for the lambda code, where all type information is erased. (To interpret the type_declaration, we would also need to keep the typing environment.) This would blur the distinction with Typedtree, and at some point, it might just make more sense to base your project on Typedtree (which would give more freedom to map high-level constructions such as pattern matching, functors, objects to more "idiomatic" JS code). Did you consider doing that?
I'm not sure exactly how you would use that in your project. But a less ad hoc approach would be to annotate Pfield with the size of the block (if known).
Breaking the concrete representation of existing types is not possible (think about the C FFI). |
Comment author: @bobzhang I did think about take it from ocaml typedtree, and it might not be that hard, but I also have to maintain the code, there is always a trade off, currently, the output is already pretty good (good enough to guarantee a good FFI)so that I am not strongly motivated to work on `from typedtree'. Yes, Pfield with size is more general, but it should be sound and complete. Introducing special instructions will not break existing C FFI, since after lambda layer, nothing is changed, the point is that the datatype representation is tailed for C, the javascript backend does not need follow the same(we loose something like marshal, but there is a way to bring it back in the future) |
Comment author: @chambart By the way I would also be interested in adding more type informations to getfield, but for other reasons. The two main ones would be the size of the original type, and the mutability of the field. The main examples would be optimizing constructions like: let a = immutable_field 1 x in In that case a and b can be safely shared. match x with can be simplified to match x with |
Comment author: @mshinwell +1 to chambart's suggestions |
Comment author: @alainfrisch It would break too much code to change the definition of ['a ref]. As for adding more type information to Lambda, if this is still relevant, this should be discussed in specific tickets. |
Original bug ID: 6994
Reporter: @bobzhang
Assigned to: @alainfrisch
Status: closed (set by @alainfrisch on 2016-07-13T07:30:10Z)
Resolution: fixed
Priority: normal
Severity: feature
Category: standard library
Monitored by: @diml @ygrek @jmeber @hcarty
Bug description
Current ref is defined as follows
type 'a ref = {mutable contents : 'a }
I suggest we hide its implementation, and change the primitive name for function "ref" and "!" accordingly, so in the lambda layer we know it's a reference or not.
The immediate benefit is that my OCaml to Javascript backend(http://zhanghongbo.me/js-demo/) would not create a block, there is an optimization pass to eliminate ref in lambda layer, but that's not complete, other benefit maybe include avoid unboxing `int ref' etc.
The cost is it might break some existing programs, but the expressivity is not lost.
The text was updated successfully, but these errors were encountered: