shelby3

So Rust has global references ownership rules, which only allow one (borrowed) mutable reference to the same object to be active in the current block scope. The objective is to prevent race conditions on the object. But from the discussion we had on the forum, a DAG tree of disjointness is not a general model of imperative programming and afaics in the general case requires dependent typing (which is known to exclude Turing-completeness). Thus I abandoned Rust's global borrowing rules, because it seems like a pita of false promises that is rarely (20% of the time?) applicable.

But I [proposed a more localized

shelby3

jl777 wrote:

why not have the way you allocate the memory determined how it behaves?

In a garbage collected (GC) language such as JavaScript, you don't actually ever explicitly allocate and deallocate memory. Thus we avoid the bug of crashing when a pointer points to memory that has already been freed, or the memory leaks due to forgetting to deallocate memory. GC languages can still have semantic memory leaks though, such as forgetting to remove an event handler. Automatic reference counting pointers have the flaw that they memory leak where there is a circular reference (pointer points to some structure which contains a pointer which points back to the struct that contains the first pointer).

So GC is much easier for the programmer than manually tracking memory allocation and deallocation. But it has one disadvantage which is that it requires up to 5X the memory to achieve the same performance, and the mark-and-sweep pauses can lockup the machine for many seconds. There are ways to improve the GC. The m

shelby3

The Union Type Quiz
===================

 0. Please give your typing approach an intuitive name:
    
Consistent, Unified Subsumption


 1. Please describe the guiding principle of your typing approach in one sentence:
    

shelby3

Version Control

Distributed Version Control

Each repository in a distributed version control system (DVCS) such as Git and Mercurial, is a [directed acyclic graph] (DAG). Each DAG node is a [cryptographic] hash that uniquely identifies (i.e. hashes or checksums) a comment, the set of changes (a.k.a. ‘commit’ or ‘changeset’) from, and the cryptographic hash of each of, the directly antecedent ‘parent’ changeset(s). A ‘merge’ changeset has multiple parents, and specifies the changes to each parent such that all those parents result in the same content.

Figure 1. ‘M’ is a merge of parents ‘D’ and ‘E’