Hi David,
thanks for reaching out -- answser inline below
On 21/02/2025 16:34, David Gregory wrote:
While we started working on this for MH/VH-related use cases (for
instance, FFM's jextract will be a big user of stable values), we
also realized that this abstraction is actually quite useful in other
cases too.
This is really exciting! Stable values open the door to some really
exciting language features, especially in functional languages.
For example, something similar is used to implement the tail-recursion
modulo cons transformation in the OCaml compiler:
https://ocaml.org/manual/5.3/tail_mod_cons.html#sec:details
This could enable languages hosted on the JVM to make all kinds of
not-quite-tail-recursive programs stack safe without using explicit
stacks to store the intermediate values.
Is it possible that the informal rules for record components will be
adjusted to allow stable fields in addition to final ones?
There's different meaning for the word "trusted". If, by that, you mean
that fields of type StableValue<X> should be trusted the same way that
record components are trusted (e.g. where "final" really means "final"),
this is something we can do. I believe the prototype we have today does
that to some extent -- but we don't know yet whether that "hack" will be
made official :-)
In a way this problem of "trust" is an orthogonal issue -- and it would
be better to wait for better support for trusting _all_ final fields
(not just those inside records, or those whose type is StableValue).
Cheers
Maurizio
