Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 15/05/2016 11:25 PM, Martin Nowak wrote:
> On 05/15/2016 02:17 PM, Daniel Murphy wrote:
>>
>> For simple types that's true.  For more complicated reference types...
>>
>> Variable indexes are not enough, you also need heap memory, but slices
>> and pointers (and references) can refer to values either on the heap or
>> the stack, and you can have a slice of a member static array of a class
>> on the stack, etc.  Then there are closures...
>
> So we do need a GC or RC for arrays, structs, classes (anything
> heapish). Values for those could be allocated by a simple bump/region
> allocator or a dedicated allocator that support individual freeing (via
> RC or GC).
>
> In any case struct Pointer { int index; /* 2B positive values for stack,
> 2B negative for heap*/ } wouldn't be much more complicated than a raw
> pointer (and a bit simpler to garbage collect).
>

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.

>> Neither e2ir or s2ir are actually that complex.  A lot of the mess there
>> comes from the backend IR interface being rather difficult to work with.
>
> Think of a simple switch statement where you even need to introduce
> relocations (or keep a list of fixup addresses) b/c you don't know the
> jump addresses in advance.

This is not exactly difficult to do.

> In a visitor you simply test the cases and execute the first case body.
>
> Not to mention that we can reuse existing solutions from the current
> interpreter (e.g. for gotos see
> https://github.com/dlang/dmd/blob/0757504342e48e272372b7ac52cda5a333b2a2bc/src/dinterpret.d#L1014
> and
> https://github.com/dlang/dmd/blob/0757504342e48e272372b7ac52cda5a333b2a2bc/src/dinterpret.d#L1094).
>

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.