Battle-plan for CTFE

[Martin Nowak via Digitalmars-d-announce]

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.