32/64 bit Numerics

[enricozb]

The current idea is to use the ERA node as a pointer. ERA's value is unused at the moment, so it could instead be used to store a 29-bit pointer. While this limits us to a 29-bit address space, the actual memory usage is unconstrained (as a pointer could refer to an arbitrarily sized object).

We will probably need a fat Object structure, which stores the type and value our heap-allocated objects have.

Partial application of operations will also have to be stored on the heap.

[VictorTaelin]

It is worth discussing what types of objects we want to support. For now, I think large numbers (u64, i64, f64, perhaps BigInt) make sense, and vector types and matrices too. But we could also support mutable arrays and immutable buffers. I'm not sure if we should do it through this mechanism though, since array operations can't be captured by the OPER interactions (how would set / get look like?).

[enricozb]

At least get is a binary operator, A get 0, but set is a good question. Also I'm very curious with an array set operation how hard it will be to reason about correctness of programs that mutate some pointer address.

[oxnan]

+1 for bigint support