3 ms·

The only limitation to the allocation patterns Xr0 imposes is that there can be no leaks. Everything else is possible. Yes, Xr0 is young. It took Rust nine yea

The only limitation to the allocation patterns Xr0 imposes is that there can be no leaks. Everything else is possible. Yes, Xr0 is young. It took Rust nine years to reach v1.0.0. Xr0 may need slightly over the nine months its had.

nneonneo 3y ago
So, please don't make (or invite) comparisons to Rust if you know you aren't there yet. Not everyone will agree that you are just making such a comparison "tongue-in-cheek". "Safer than Rust" is an extremely high bar to clear, and you haven't done so, so why title your blog post that way? I am curious to know how you would handle tagged unions, say, something like this: struct object { int type; /* OBJ_INT, OBJ_STR, etc. */ union { int i; char *s; /* heap allocated */ /* etc */ } val; }; Does Xr0 prevent type confusion, and can it model the data-dependent behaviour of any functions that operate on struct object? How would you model things like reference counting? In CPython, for example, one of the most pernicious programming problems is invalid reference counting because the C API functions are rather inconsistent in their handling of reference counts. One has to carefully peruse the documentation to understand if the function will steal a reference (from a parameter), borrow a reference (for the return value), or if it makes a new reference. Such setups are perfect candidates for annotation.
- akiarie 3y ago
  Can you give an example of the kind of data-dependent behaviour you have in mind? We haven't implemented unions yet, but I see no reason why the approach we describe in the article cannot propagate the tagging info in such a struct. As we explain in the article, Xr0's focus on formalising interfaces allows the verification of each function to be carried out independently. Thus we do reference counting only within individual functions. I'm not sure I fully understand the CPython example. What I can say is that the annotations allow us to capture the semantics such as whether a function destroys a value, stores its value in a global or returned value, or has no net effect on the state of its caller.

nneonneo 3y ago

So, please don't make (or invite) comparisons to Rust if you know you aren't there yet. Not everyone will agree that you are just making such a comparison "tongue-in-cheek". "Safer than Rust" is an extremely high bar to clear, and you haven't done so, so why title your blog post that way? I am curious to know how you would handle tagged unions, say, something like this: struct object { int type; /* OBJ_INT, OBJ_STR, etc. */ union { int i; char *s; /* heap allocated */ /* etc */ } val; }; Does Xr0 prevent type confusion, and can it model the data-dependent behaviour of any functions that operate on struct object? How would you model things like reference counting? In CPython, for example, one of the most pernicious programming problems is invalid reference counting because the C API functions are rather inconsistent in their handling of reference counts. One has to carefully peruse the documentation to understand if the function will steal a reference (from a parameter), borrow a reference (for the return value), or if it makes a new reference. Such setups are perfect candidates for annotation.

akiarie 3y ago
Can you give an example of the kind of data-dependent behaviour you have in mind? We haven't implemented unions yet, but I see no reason why the approach we describe in the article cannot propagate the tagging info in such a struct. As we explain in the article, Xr0's focus on formalising interfaces allows the verification of each function to be carried out independently. Thus we do reference counting only within individual functions. I'm not sure I fully understand the CPython example. What I can say is that the annotations allow us to capture the semantics such as whether a function destroys a value, stores its value in a global or returned value, or has no net effect on the state of its caller.