On 05/15/2016 04:00 PM, Daniel Murphy wrote: > The problem is, if index refers to a single variable on the stack, then > it's insufficient to refer to a variable inside an aggregate on the > stack. Then you need to start building constructs for member of struct > in array of struct pointers and it gets fairly messy... It's all > solvable, I'm not sure the simplicity would survive.
Taking what I said further down below there would be one union Value type (untagged b/c the compiler knows what it is). Then an Array could be implementd as HeapValueRef[], a hash table as HeapValueRef[ValueRef], a struct/class as HeapValueRef[] (with HeapValueRef being a pointer or int to a heap allocated Value and ValueRef being a pointer or int to either a stack value or a heap value). A D Pointer/Ref would just be a ValueRef in the interpreter and the aforementioned int (2B + for stack, 2B - for heap) encoding should still work for that. Depending on how much pointer arithmetic we support, Pointer must contain a ValueRef to the outermost aggregate and needs to store the type of that an additional byte offset. The type and offset could then be used to compute the actual pointee. While that sounds a bit complex, it's merely just https://en.wikipedia.org/wiki/Offsetof. > Flow control is really not where the complexity lies IMO. The weird > ways in which different types of reference types can combine leads to > either very complicated or very low level descriptions of memory. Maybe you're right, but it'll be hard to figure out w/o an actual implementation. And the AST still looks like a lot less to code and execute.