I've explained myself poorly.
By default my description uses borrows/references/pointers, even across functions, loops and threads, until it violates the Shared Xor Mutable rule, which it fixes by cloning or prevents with a compiler error.
fn main() {
let mut point_1 = Point { x: 3, y: 4 };
point_1 = double(point_1);
dbg!(point_1);
}
fn double(p: mut Point) -> Point {
p.x += p.x;
p.x += p.y;
p
}
If the above code was Rust, it's sort of restricting mutation to the local scope, but it's definitely not using copies, since Rust doesn't do that. It uses something like a mutable borrow/reference. My description does the same thing.
If we wanted a second point, and we also wanted to use the first point, we would need to clone the first one.
// IMPORTANT: This is Rust code, not the system I describe.
fn main() {
let mut point_1 = Point { x: 3, y: 4 };
point_1 = double(point_1);
// This would move point_1, but we want to reuse point_1 later.
// let point_1 = double(point_1);
// We have to clone point_1
let point_2 = double(point_1.clone());
draw_line(point_1, point_2);
}
Maybe a better way to describe it is that the return value and the assignment negotiate what to borrow without needing separate borrow syntax. A function returning a parameter indicates that it's mutating that parameter, and the function caller assigning the return value to something indicates what variable the function is allowed to mutate.
The following Rust snippet does the same thing.
fn main() {
let mut point_1 = Point { x: 3, y: 4 };
double(&mut point_1);
// Cannot do because that would create a shared mutable reference.
// let point_2 = double(&mut point_1)
// Must clone point_1.
let point_2 = double(&mut point_1.clone());;
draw_line(&point_1, &point_2);
}
The following Python snippet is similar:
def main():
point_1 = Point(x=3, y=4)
double(point_1)
// Cannot do because it would get changes from point_2.
// point_2 = point_1
point_2 = Point(point_1.x, point_1.y)
double(point_2)
draw_line(point_1, point_2)
// Point(6, 8) to Point(12, 16)
Python would allow us to do point_2 = point_1, but then when we double point_2 that would also double point_1, creating a line from x: 12, y: 16 to x: 12, y: 16.
The Koka docs indicate that mutable variables cannot be sent out of scope, while my description doesn't have this limitation. Mutable variables can be passed around freely.
My description allows mutation of external variables, similar to how Rust does it, but instead of &mut, it uses function signatures and the call site’s inputs and outputs (assignment), like I showed in the example code above comparing Rust and Python.
I believe it's efficient enough to calculate.
There's basically five types of functions.
- Functions that create and return a variable.
- Functions to mutate a variable, that take a mutable parameter, mutate it, and return it.
- Functions that only take an immutable parameter for things like printing it to the console or sending it over the network. There is no return value.
- Functions that take multiple immutable parameters and also return one or more of them, such as taking two strings and returning the longer one for further processing.
- Functions that take ownership, either mutable or immutable, for closing resources like files and network connections. Closing does not return the closed parameter.
This information is used for inferring the ownership and lifetimes of variables, and can be cached for speed.
Within a function, ownership and lifetimes are easy enough to track, even for a human.
This isn't more work than the Rust compiler does, so it shouldn’t encounter the halting problem.
Yeah, I'd misunderstood Perceus the first time. The system I describe is a lot like compile time reference counting. To clarify, Koka/Perceus also does the work at compile time and does not require a run time system, but it's different from the system I describe because mutable variables cannot be returned from functions in Koka, as I mentioned above.
As I said above, there's only one place where my system performs a copy, and it absolutely has to perform that copy for correctness and safety, just like Rust. If it reused the same reference, like plain reference counting without copy-on-write, then it would cause incorrect and even unsafe behaviour, such as using the same reference for sorting a list, which would make the “unsorted” list point to the same data as the “sorted” list.
As I said above, my description allows free mutation of variables and passing them around easily. It even allows safely mutating variables from within a loop, for example.
In the example below, it loops over from without mutating it. It only mutates to two times for each iteration.
fn main() {
let first = ["ay", "bee", "sea"];
let mut second = vec![]
second = copy_items(first, second)
dbg!(vec)
// [
// "ay", "ay!!",
// "bee", "bee!!",
// "sea", "sea!!"
// ]
}
fn copy_items(from: [String], to: Vec<String>) -> Vec<String> {
for str in from {
to = push(to, str)
to = push(to, string_join(str, "!!"))
}
}
Because main calls the function with vec_2 and also assigns the result back to vec_2, the function mutates it in-place using a borrow.
Like I said above, there's basically only one place it performs copies, and it has to do that to avoid shared mutability and the problems it brings.
As I said above, my description uses pointers/borrows/references under the hood, even across function bodies and scopes. The comparison to the Rust and Python examples should show the similarities.
Like I said above, I am using mutable borrows/references under the hood, even across function and loop boundaries, but without separate borrow syntax for beginners to manage.
I hope the Python and Rust comparisons help explain my proposal better. The system I describe basically allows everything that Python and other high-level languages allow[1], but with the safety and performance of Rust.
Thanks for all the feedback!
Except for circular references, which can solved by a special internal reference type that I mentioned in previous posts. ↩︎
Sometimes it turns out to be entirely doable, like fixing drop flags in Rust was. Which case is this? No idea.