Help wanted: Proposal - Simple rules for V safety

[krolaw]

I've created a gist drafting how I perceive V could be completely safe using coroutines and without rust complexity, and I've dropped ptrs.

https://gist.github.com/krolaw/000a8bfb72483880a691dcbd00ae4919

Looking for feedback.

Thanks.

[medvednikov]

Thanks @krolaw

So you suggest only having channels to modify data concurrently.

My initial idea was to have a lock{} block thats ads mutex.lock()/unlock()

Also the plan is to translate Go code in the future, so this feature may be necessary.

[krolaw]

@medvednikov I saw lock, but it relies on the dev getting it right. Also locks would probably need labels, for sections of different code accessing the same mutable data, and that's getting more complicated.

My suggestion hopefully means you can't have a race (like rust).

[krolaw]

Just updating proposal with point 4, which essentially deals with rust's borrowing of mutable data in a way that I think is much simpler.

[runeimp]

@krolaw I like a lot of these concepts but I'm a little fuzzy on number 4. So for the last example the system is doing something along the lines of

mut b := 7
c <- b // Where after the value of b is sent over the channel it is set to a special token that denotes it's inaccessible?
b <- c // Replaces the special token with the value returned from the channel
z := b // Now works because were not trying to assign the special token to a new variable?

If that is the case I don't believe it would generate a compile time error in many cases. But would generate a runtime error. Given the nature of concurrency using any system I don't know we can guarantee the timing. Unless the channel receiver is above the assignment in the same block and the channel is also blocking by default. Which could potentially lead to deadlock under the right circumstances, no? I do not have extensive experience with concurrent programming but these are my initial thoughts. Are channels blocking by default in V? The docs are pretty sparse on concurrency and no mention of channels I could find.

[medvednikov]

By the way for # 4 the syntax should be

go fn(mut i) {
  ...
}(mut x)

[krolaw]

@runimp @medvednikov I've made things a bit more flexible (easier to code) and updated the gist.
I'd value your thoughts.
I was wondering if "for in" could do double duty for iterators and channels.

mut b := 7
c <- b // b is now on the channel. b can still be read, as long as any code at the other end of the channel does not write to it. If any code at the other end of the channel writes to it, it is inaccessible.
b = <- c // Not allowed! You don't know how long the channel is, you may not get back the original b.
b = mut <-c // Allowed as b gets a new allocation, unrelated to previous allocation
z := b // Works always in this example because of the previous line. It would be a compiler error, if b had been passed to channel where the other end could write to it OR passed to coroutine that writes to it.

[krolaw]

@runeimp

I'm not a huge fan of mut e := mut b // e is mutable and shares the same data as b

How do you share data without pointers?

You don't. For data to be shared you do need pointers. However if b never changes or is read again the compiler can get away with a copy.

They're just labels instead of variables?

mut is an indicator to the compiler. A simple implementation could replace mut with &.

Is that how V handles variables currently, like Python?

Sorry don't know.

The syntax seems to stutter and otherwise seems prone to being overlooked as shared data.
Regarding number 2 maybe something like:

mut e <= b // e is mutable and shares the same data and data type as b which must also be mutable
or maybe even better, mut e <=> b, mut e :=: b, or mut e :: b?

If the shared state is unique it's syntax needs to stand out as the exception and not the rule.

I disagree. I believe the mut keyword is all you need.

x := b // x is an immutable copy of b, if b is immutable or never changes after the allocation the compiler could get away with x := &b if it improves performance. Otherwise x := b.
mut x := b // x is a copy of b, which is now mutable. If b is never accessed again, the compiler could choose between x := b and x := &b.
mut x := mut b // x and b share same data. So you would expect x := &b. However if b isn't accessed or set again, a copy would do.

So effectively mut is an indicator of sharing intent. Depending what is actually done, the compiler can decide whether pointers should be used.

Hope that helps.

[krolaw]

Hi all,

It had been bothering me that in order to ensure concurrent safety and flexibility the compiler would have to traverse the entire code tree to assess how a mut variable would be used when passing it into a channel/coroutine.

Turns out it is unnecessary as the compiler rejects any mut variables that do not have a path that causes the value to change This simplifies things drastically, as a mut receiver must have a path that changes its value - no need to traverse.

Thus the only concurrent rule required is: Any mut variable after being passed to a channel or coroutine's mut receiver, must no longer be accessed (read or write).

I'll update the proposal soon.

Thanks.

[krolaw]

Discussed with @medvednikov various aspects of mutability. I have updated the gist based on those discussions.
Essentially:

1. Mutable values and mutable references are different types and variables cannot switch between the two.
2. References are denoted with & (not mut or ref).
3. When operating on a reference it's value is used, unless & is prefixed. (i.e. mut c := d, c is receiving a value, regardless if d is a reference (it is auto dereferenced).
   Hope it makes sense.

[krolaw]

I've been reworking channels to support selects, and I think refs may be a mistake. They make sense when used implicity with functions/methods for mutability, but having two (or more) ptrs to the same memory location is going to make "having no undefined behaviour" extremely difficult (in terms of usage rules and compiler implementation) when it comes to coroutines. I'm wondering (beyond implicit function ptrs), if refs are actually that useful anyway and can they simply be done away with?

I'm not saying ptrs wouldn't be used by the compiler (for speed), they would, but automatically, especially when "copying" large immutable objects. Or "copying" large mutable objects to immutable objects under certain conditions.

How is:
mut a := 3
mut b := &a
useful?

Structures with refs and arrays of refs may cost us "no undefined behaviour" or some massive complexity rules or both. So I'm just trying to get a handle on how important they are.

Maybe refs can only exist in "unsafe" V code, allowing for importing of C etc, but "safe" v code doesn't allow them?

[cristian-ilies-vasile]

@krolaw
Please take a look at how Pony language deal with inherent issues of data races.
"the type system ensures at compile time that your concurrent program can never have data races"

Regards,
Cristian.

What makes Pony different?
An Early History of Pony

[krolaw]

Pony and V's proposal are essentially the same.

1. Pony uses guaranteed order message passing to actors. V uses go like channels.
2. Pony only allows immutable or vars with a single reference to be used concurrently. Pony has 3 keywords controlling this (iso, val, tag) . V doesn't need any, the rule is simple. If a mutable object is passed to another coroutine (channel or go call), it can no longer be used. (So pass a copy or wait until it is passed back.) Same benefits, simpler rules.

[cristian-ilies-vasile]

@krolaw
mut keyword tells the compiler that a read only variable is now writable.
I would like to suggest an unmut keyword to place that variable back in read only state.

[krolaw]

@cristian-ilies-vasile it certainly does not. An immutable variable never becomes mutable. You can take a mutable copy, but that's it.