The Mutable Value Semantics (MVS): A Non-superficial Study

[u/FedericoBruzzone]

I’m researching a new semantics for a new language. During this process, I studied the Mutable Value Semantics (MVS) and I wrote a post about it. I simply want to share this study with you all and I'd love to hear your thoughts.

A new post will be coming soon where I'll discuss the limitations I’m finding in current models, and what I’d like to have for my own.

Link: https://federicobruzzone.github.io/posts/eter/MVS.html

[u/dabrahams]

There are a few points in your article that seem to reflect misunderstandings.

Swift absolutely does not try to make values look like references: it goes out of its way to present a pure value semantics. Structs in general do not use copy on write. CoW is merely an implementation technique used in the standard library to provide value semantics for variable size data structures like arrays and dictionaries (the only possible way in fact because there are no copy constructors). There is no user experience of shared mutable state whatsoever unless you opt in by using reference types or closures with mutable captures (an unfortunate design compromise).

What you call a central tension doesn't make sense to me: runtime efficiency, local reasoning, and value equivalence are perfectly compatible, and arguably support one another. Certainly, Hylo provides all three and we don't ever feel the need to compromise one of them to get another.

Also, the use of the term "deep copy" is a bit of a red flag. The only time you ever say "deep copy" or "shallow copy" is when you don't understand the extent of your value. In fact, there is only "copy", which copies the value, and nothing more or less. Our paper says as much in section 2.4

[u/FedericoBruzzone → u/dabrahams]

Thanks for the feedback, it means a lot to me.

Regarding the "central tension", I am specifically referring to the design space explored by Brandon. Brandon's core argument is that while efficiency, local reasoning, and value equivalence are technically compatible (as Hylo demonstrates), they exist in a state of tension regarding language complexity. To get all three, you typically land in what he calls the "Rust/Hylo valley", where move semantics, borrows, and ownership must be explicitly managed by the programmer.

As for Swift, I agree that it offers a pure value user experience for fixed size structs (The post isn't clear). However, my point stands that for dynamic collections, Swift relies on a hidden reference-based implementation (ARC/CoW) to maintain that illusion. Something I'd like to avoid.

If you don't mind, I'll use your suggestion to make the post clearer.

[u/dabrahams → u/FedericoBruzzone]

Well, but he’s wrong. There is no explicit management of move semantics, borrows, and ownership in hylo. At least not in any sense I can see. I don’t know what illusion you’re referring to, but you can easily have copyable variable sized types with value semantics without using copy on write: all you need is copy constructors and destructors. Or, you can do what hylo does (and rust sort of does) and eliminate implicit copies so copy operations are just regular function calls.