sixten VS pony-tutorial

Immutable data structures don't necessarily require more memory: they can avoid deep copies. They are also automatically thread safe without expensive (slow) locking mechanisms. They also don't necessarily reduce cache locality. The reduced cache locality in the case of Haskell (I think) mainly comes from the representation of objects in its implementation (improved STG) which uses extensive boxing and jumps that hinder both spatial and temporal locality (require review/comment from GHC/Computer Architecture experts, take it with a grain of salt). Objects can be much more efficiently represented if not for the need to implement lazy (call-by-need) semantics. See sixten and futhark for examples.

[Sixten](https://github.com/ollef/sixten): functional programming with unboxed data by default.

I can't answer this well and don't know of any resources, but I have seen it before in the parser for sixten:

    https://github.com/ollef/sixten/blob/60d46eee20abd62599badea85774a9365c81af45/src/Frontend/Parse.hs#L458

Sixten is a language that allows precise control over memory layout of algebraic data types.

For something more peripherally related, check out Sixten. Its focus is on using unboxed value representations, which is in spirit close to what you are proposing, and some of its ideas might be good inspiration.

I don't think that there is a book written about Pony, but the tutorial and the list of patterns (WIP) are all you need to learn the language.

[Pony](https://tutorial.ponylang.io/): actors, reference capabilities, object capabilities.

Pony is a relatively young but interesting language with capabilities-security.

Well, depends on how you define ownership. Pony 's type system has reference capabilities which let you define who's allowed to do what to a reference and part of it sort of deals with ownership (along the lines of "this actor is allowed to do Y to the reference, other actors are allowed to do Z"). You can eg. have methods that return an isolated value that guarantees that there are no other references to that value, meaning it's automatically thread safe. You can also define things as vals which says that they are globally immutable, refs which give the current actor read/write capabilities but can't be shared with other actors

The alternatives are:

- Division must be impure (because it can throw an exception)

- Division must be partial - i.e. return Option[Int].

Both seem worse compared to defining division by zero as zero. Coq, Lean, and Pony do the same. https://github.com/ponylang/pony-tutorial/blob/master/conten...