Mutable value semantics is really cool. It gives you freedom from aliasing without a complicated type system, it eliminates the value/reference distinction that most languages have (e.g. int vs Integer in Java), and it turns ref counting into a complete solution for GC because cycles become impossible.
One of their research papers listed on this page, “ Who Owns the Contents of a Doubly-Linked List?” discusses how to represent graphs with mutable value semantics. I was too sleepy to read them yesterday, but several of their papers look interesting.
Their answer seems to be: store the data in an array / hashmap and go through indices / keys link. I came away a bit disappointed from this paper since I have seen (and used) this solution in a couple of projects before.
That said, I think mutable value semantics is a very interesting paradigm, I copied their earlier design for my language and have been writing with this style for some time now.
See, these all sound like a good thing, but you can already do this just by... getting rid of mutation. And we already know everything about how it works. I guess I'll have to look at this again and read the papers.
Well, yeah. The point of mutable value semantics is that you can get the benefits of functional programming while also straightforwardly mutating things (without any Monads or Arrows).
How does the expressivity of subscripts compare to that of Rust-style lifetimes?
From skimming through the docs, it seems like subscripts are somewhat comparable to a closure providing a temporary reference to a value. That seems kinda limiting in that you can’t write stuff like…
let mut x = vec![big_object()];
let y = HashMap::from_iter([(big_object(), 42)]);
let key = &x[0];
let value = &y[key];
// ‘key’ can expire here and we can maintain access to `value`
// because the signature is `get<'a, 'b>(&'a self, k: &'b K) -> &'a V;`
x.clear();
println!("{value}");
…which would be illegal because you’d be borrowing x mutably within a closure borrowing it immutably. You couldn’t obtain a reference to the value living longer than that immutable borrow of x because of the structure forced upon you by the subscript’s closures.
Am I mistaken? Is this type of scenario just not as common as I worry it might be?
I think your understanding is correct. And yeah, it's less flexible than Rust in that you can't distinguish different lifetimes as in your example. It's also more flexible than Rust, in that you can pass large objects around without worrying about lifetimes (since it's essentially wrapping the large object in an Rc under the hood and calling .clone() for you). Another way of viewing this is that it erases Rust's distinction between &T and T: you get implicit copies like &T but an unlimited lifetime like T.
As far as how this is in practice, I'm not sure. My understanding is that R and Swift are both like 2/3 mutable value semantics, and people don't seem to complain that it's impossible to program in Swift, though maybe anyone that really wants mutable aliasing is using the remaining 1/3. I'm really curious how Hylo will fare once it's more complete.
No, you're right. But subscripts in hylo are not literally closures but for easy examples they map pretty closely to what you sketched. hylo does support (will support?) nested subscripts, which compile to something closer to a coroutine than a closure, here's a relevant discussion between hylo and swift devs.
The tour and specification have a prominent warning that they’re outdated. Seems like you’d need to look at the compiler source code to learn the features and read the papers to understand what they’re good for.
justinpombrio | 17 hours ago
Mutable value semantics is really cool. It gives you freedom from aliasing without a complicated type system, it eliminates the value/reference distinction that most languages have (e.g. int vs Integer in Java), and it turns ref counting into a complete solution for GC because cycles become impossible.
[OP] fanf | 11 hours ago
One of their research papers listed on this page, “ Who Owns the Contents of a Doubly-Linked List?” discusses how to represent graphs with mutable value semantics. I was too sleepy to read them yesterday, but several of their papers look interesting.
tjammer | 10 hours ago
Their answer seems to be: store the data in an array / hashmap and go through indices / keys link. I came away a bit disappointed from this paper since I have seen (and used) this solution in a couple of projects before.
That said, I think mutable value semantics is a very interesting paradigm, I copied their earlier design for my language and have been writing with this style for some time now.
cmcaine | 6 hours ago
Yeah, it seemed to just show that you can bypass the ownership/value rules if you use bootleg references.
Just feels like a worse solution than using the programming language’s reference type.
icefox | 8 hours ago
See, these all sound like a good thing, but you can already do this just by... getting rid of mutation. And we already know everything about how it works. I guess I'll have to look at this again and read the papers.
justinpombrio | 4 hours ago
Well, yeah. The point of mutable value semantics is that you can get the benefits of functional programming while also straightforwardly mutating things (without any Monads or Arrows).
radbuglet | 8 hours ago
How does the expressivity of subscripts compare to that of Rust-style lifetimes?
From skimming through the docs, it seems like subscripts are somewhat comparable to a closure providing a temporary reference to a value. That seems kinda limiting in that you can’t write stuff like…
…since, with subscripts, you’d be writing…
…which would be illegal because you’d be borrowing
xmutably within a closure borrowing it immutably. You couldn’t obtain a reference to thevalueliving longer than that immutable borrow ofxbecause of the structure forced upon you by the subscript’s closures.Am I mistaken? Is this type of scenario just not as common as I worry it might be?
justinpombrio | 3 hours ago
I think your understanding is correct. And yeah, it's less flexible than Rust in that you can't distinguish different lifetimes as in your example. It's also more flexible than Rust, in that you can pass large objects around without worrying about lifetimes (since it's essentially wrapping the large object in an
Rcunder the hood and calling.clone()for you). Another way of viewing this is that it erases Rust's distinction between&TandT: you get implicit copies like&Tbut an unlimited lifetime likeT.As far as how this is in practice, I'm not sure. My understanding is that R and Swift are both like 2/3 mutable value semantics, and people don't seem to complain that it's impossible to program in Swift, though maybe anyone that really wants mutable aliasing is using the remaining 1/3. I'm really curious how Hylo will fare once it's more complete.
tjammer | 3 hours ago
No, you're right. But subscripts in hylo are not literally closures but for easy examples they map pretty closely to what you sketched. hylo does support (will support?) nested subscripts, which compile to something closer to a coroutine than a closure, here's a relevant discussion between hylo and swift devs.
Student | 19 hours ago
The tour and specification have a prominent warning that they’re outdated. Seems like you’d need to look at the compiler source code to learn the features and read the papers to understand what they’re good for.
justinpombrio | 17 hours ago
I would guess that the tour and spec are still fine places to go to get a sense of the language, if your aim is to learn about its interesting ideas.
If you want to look at papers, I think Implementation Strategies for Mutable Value Semantics is the one to read.