On Monday, 2 December 2019 at 23:18:55 UTC, rikki cattermole wrote:
> I only just watched the talk a couple of hours ago.

Ah, then you have more info on this than me.

> There is one key feature that both of us share.
> Objects life times get owned by a data structure.
>
> In both of my examples in the code proposal I linked above were based upon just this. Some sort of object (either a class or the double linked lists nodes) is owned by some sort of data structure (Scoped vs DoubleLinkedList).

Ok, maybe I misread the intent you were conveying. Since I haven't watched the talk yet, I don't know how they ensure the integrity. I would suspect they use the type system...

> I am not convinced about their memory region scheme, based upon the talk it looks to be prone to data races with locks. Which is worrying.

It is possible that they intend to use a verifier that prove that deadlocks or starvation cannot happen since they design a new language from scratch? Or put that on the programmer?

( they rule out dataraces as only one thread has access to the region)

> But so far I'm getting convinced that my idea isn't completely crazy.

Maybe write up something more detailed? I believe "separation logic" has been used for partitioning the heap into groups of objects, but I don't know how it works... Probably intricate.

> I'm going to try and reach out and get a confirmation on how their memory region system works.

You could ask if they have pointers to papers, perhaps?

On 03/12/2019 7:35 PM, Ola Fosheim Grostad wrote:
> On Monday, 2 December 2019 at 23:18:55 UTC, rikki cattermole wrote:
>> There is one key feature that both of us share.
>> Objects life times get owned by a data structure.
>>
>> In both of my examples in the code proposal I linked above were based upon just this. Some sort of object (either a class or the double linked lists nodes) is owned by some sort of data structure (Scoped vs DoubleLinkedList).
> 
> Ok, maybe I misread the intent you were conveying. Since I haven't watched the talk yet, I don't know how they ensure the integrity. I would suspect they use the type system...

Its not described in the talk. It was pretty light on the details we'd need.

>> I am not convinced about their memory region scheme, based upon the talk it looks to be prone to data races with locks. Which is worrying.
> 
> It is possible that they intend to use a verifier that prove that deadlocks or starvation cannot happen since they design a new language from scratch? Or put that on the programmer?
> 
> ( they rule out dataraces as only one thread has access to the region)

They rule it out once you 'own' a region.

I'm concerned about how they go about 'owning' it.

E.g. locks end in the same problem as though it was on individual object.

>> But so far I'm getting convinced that my idea isn't completely crazy.
> 
> Maybe write up something more detailed? I believe "separation logic" has been used for partitioning the heap into groups of objects, but I don't know how it works... Probably intricate.

I'm not the right person to do this.
Lifetime's are a bit over my head.
In my code example I hand waved a bunch of details related to it.

But basically its a head const reference tied to the lifetime of the owning memory e.g. a data structure. That guarantees no pointer modification at any point in time.

>> I'm going to try and reach out and get a confirmation on how their memory region system works.
> 
> You could ask if they have pointers to papers, perhaps?

They do and the project is meant to be released in a couple of weeks.
Right now they don't have a compiler, so yeah... Lots of theory wishy washy atm.

On 11/23/2019 7:42 PM, Jab wrote:
> I'm not too keen on testing it now. The only reason I'd see to test it is to find any flaws in the system, the doc provided illustrates that there is still a lot of known issues that need to be resolved first. Who knows what kind of changes will be made in that time.

The point of testing it within what is implemented is to test to see if it works as a concept. If it doesn't work as a concept, there is no point in expending the effort to fill in the corners.

On 11/23/2019 8:05 PM, mipri wrote:
> And this crashes dmd:
> ---
> import core.stdc.stdlib: malloc, free;
> 
> @live void zoo() {
>      int* p = cast(int*)malloc( int.sizeof * 2 );
>      foo(p, p + 1);
> }
> 
> @live void foo( scope int* p, scope int* q ) {
>      *q = 10; // use after free.
> }
> ---
> core.exception.RangeError@dmd/ob.d(1526): Range violation

Good. I'll take care of that.

On Tuesday, 3 December 2019 at 07:14:23 UTC, rikki cattermole wrote:
> Lifetime's are a bit over my head.
> In my code example I hand waved a bunch of details related to it.

I found this master thesis on adding lifetimes to Whiley very readable, explained in english and not a lot of formalisms:

http://homepages.ecs.vuw.ac.nz/~djp/files/MSCThesisSebastian.pdf

The difference between this and Rust seems to be that: 1. Rust now ends the lifetime at last use and not at the end of the scope. 2. Rust infers the lifetime variables when they have not been explicitly given, but that is a minor difference.


> But basically its a head const reference tied to the lifetime of the owning memory e.g. a data structure. That guarantees no pointer modification at any point in time.

Hm, I think I would need a more elaborate description to understand what it can express.


> They do and the project is meant to be released in a couple of weeks.
> Right now they don't have a compiler, so yeah... Lots of theory wishy washy atm.

So it was a christmas-teaser... :-) We will have to wait and see then, I guess.

On 12/3/2019 12:20 AM, Walter Bright wrote:
> Good. I'll take care of that.

Pushed a fix.