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.

Sign up for GitHub

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

Jump to bottom

caml_modify with int type parameter in GADT #7722

Closed
vicuna opened this issue Feb 6, 2018 · 3 comments
Closed

caml_modify with int type parameter in GADT #7722

vicuna opened this issue Feb 6, 2018 · 3 comments
Labels
back-end bug Stale

Comments

@vicuna
Copy link

vicuna commented Feb 6, 2018 •
edited by trefis

Original bug ID: 7722
Reporter: smuenzel-js
Status: acknowledged (set by @xavierleroy on 2018-02-17T17:07:09Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.06.0
Category: back end (clambda to assembly)
Monitored by: @hhugo @gasche

Bug description

When mutating a member of a record with an existential type, a caml_modify is generated even though it is know that the member can only hold immediate values.

module Kind = struct
  type _ t =
    | Int : int t
end

module R = struct
  type t =
    | T :
        { kind : 'a Kind.t
        ; mutable m : 'a
        } -> t
end

let mutate r (v : int) =
  let open R in
  let T ({ kind = Kind.Int; _} as r) = r in
  (* caml_modify is used here, even though r.m can only
     contain ints *)
  r.m <- v
@vicuna
Copy link
Author

vicuna commented Feb 17, 2018

Comment author: @xavierleroy

The compiler errs on the side of caution: it generates a caml_modify operation unless it can positively prove that it's not needed. With GADTs such proofs are delicate and very error prone. So, maybe it's for the best that we're not trying to optimize this example.

@github-actions
Copy link

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

lpw25 commented May 7, 2020

This is fixed on trunk

@lpw25 lpw25 closed this as completed May 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
back-end bug Stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lpw25 @vicuna