That&#x27;s great!! Yes, <i>create-array</i> was just a version I created so I could teach arrays separate from <i>new</i> and addresses. But it creates an array on the &#x27;stack&#x27; (default space) so there&#x27;s no way to take an address of it. I quickly take my students past it to <i>new</i>.<p><i>memory-should-contain</i> doesn&#x27;t currently support named locations, sorry. Part of the problem is that with spaces a name can have many different addresses in different functions. So my tests write stuff I want to check in raw numbered locations, and the first 1000 addresses are reserved for tests so that names can never be clobbered.<p>I looked at Rust&#x27;s borrow checker for a bit but wasn&#x27;t smart enough to understand how it works or transplant it easily. I also noticed that it wasn&#x27;t smart enough to deal with things like doubly-linked lists without reaching for ref-counting. So I figured I&#x27;d keep things simple and just use ref-counting for everything. That way I punt on all the complicated static checks in favor of a simple runtime one.<p>The rule is: <i>new</i> returns <i>shared:address</i>, and <i>get-address</i> and <i>index-address</i> (and <i>maybe-convert</i>) return <i>address</i>. Use <i>shared:address</i> to pass things around between functions, and reserve non-shared addresses only for short-term operations, usually mutations. Since non-shared addresses are not dynamically allocated, there&#x27;s no possibility of use-after-free so they don&#x27;t need to be refcounted, and you can copy them around as much as you like.<p>Use-after-free and related memory corruption is really the only thing I&#x27;m concerned about protecting my users from. Memory leaks I plan to have tools for, so that programmers can identify and break them down when memory becomes a concern, but not worry about until then. I call this &quot;zero-developer-cost abstractions&quot; :) It feels less restrictive and more dynamic than Rust.<p><i>Edit</i>: I just took a look at your code, and it feels perfectly idiomatic. Nice job. Only issue I found was that you forgot to specify the outputs of <i>find</i> in its header. So its calls end up doing some runtime type-checking. I should probably raise a warning in this situation. Thanks again.