-
Notifications
You must be signed in to change notification settings - Fork 88
Implement let mutable
#3964
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
base: main
Are you sure you want to change the base?
Implement let mutable
#3964
Conversation
Parser Change ChecklistThis PR modifies the parser. Please check that the following tests are updated:
This test should have examples of every new bit of syntax you are adding. Feel free to just check the box if your PR does not actually change the syntax (because it is refactoring the parser, say). |
I've been leaving myself comments in the diff (all start with |
I think there are some tricky questions to be asked and answered wrt modes - let's discuss in other channels. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a quick pass over some of the places where you had questions - we'll chat more tomorrow.
typing/env.ml
Outdated
lookup_error loc env (Not_an_instance_variable name) | ||
Instance_variable (path, mut, cl_num, Subst.Lazy.force_type_expr desc.val_type) | ||
| Val_mut, Pident id -> | ||
let rec mode_of_locks mode = function (* jra: surely this is incorrect *) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an ongoing discussion with @riaqn about this, but my guess is we want to do something like the inverse of the walk_locks
function above. Note how that function is used by type_ident
in Typecore
: basically, it tells you how you need to change the mode of something to push it down through locks from its declaration site to a use site. Here, we're doing this in the other direction - we want to know what mode we should require something to have so that it is safe to push it up through the locks from the place where the value is to the place where the mutable variable we're sticking it in is declared.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - I've now read everything except the modes bits we're going to discuss with @riaqn.
val y_12 : t_12 = Foo_12 42 | ||
|}] | ||
|
||
(* Test 13: modes? *) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just leaving a note to remind us to revisit this after we chat with Zesen.
This feature makes explicit an existing optimization which puts `ref`s in registers or the call stack (which eliminates an allocation). See `jane/doc/extensions/_08-miscellaneous-extensions/let-mutable.md` for more. Most relevant functionality is tested in `testsuite/tests/typing-local/let_mutable.ml`, though other tests have been modified (e.g. `typing-local/alloc.ml` now makes sure `let mutable` does not allocate).
Implement
let mutable
.This feature makes explicit an existing optimization which puts
ref
s in registers or the call stack (which eliminates an allocation). Seejane/doc/extensions/_08-miscellaneous-extensions/let-mutable.md
for more.Most relevant functionality is tested in
testsuite/tests/typing-local/let_mutable.ml
, though other tests have been modified (e.g.typing-local/alloc.ml
now makes surelet mutable
does not allocate).