Stephen Kell

If we do this, then our subobject-traversal code will gain a new case (alongside struct, union and array).

Let's think about x86 some more. Ideally, a decode function would not only give us the length of the instruction, but also a precise type of the instruction (prefixes, opcodes,...

Another way to think of this: a packed seq has no element type. It only has a decode function, which enumerates the element types as it goes along.

What happens if a `get_type()` query comes in landing in the middle of a packed seq? The decode operations are potentially expensive. Maybe that's not our fault? Maybe we (configurably)...

So it seems that packed sequences, together with some notions of read-validity and write-operation, are our replacement for `make_precise()`. Does this handle everything we need? If we are to have...

Another wart is that packed sequences can't be written to without messing stuff up, in the case where an element's size is changed. So now I'm thinking it's a kind...

Radical thought: maybe we only need allocators, and this 'uniqtype' thing is one abstraction too many?

There is now a packed sequence allocator. Thinking about x86 again, we could imagine expanding x86 instruction format into a series of struct types. But then there'd be an overarching...

Our replacement `clone()` could pre-create the bigallocs (stack and stackframe). If the clone fails, the memory is arguably morally still a stack. If it gets deallocated by `munmap()`, we would...

Another issue is the allocsite metadata, including static allocation info, for the meta-objects. I think this would need to be generated online, rather than precomputed in a -meta-meta .so.