Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Monday, 9 May 2016 at 18:19:53 UTC, David Nadlinger wrote:
> Hi Stefan,
>
> On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
>> My Plan is as follows.
>
> I think you guys talked about it at the conference, but be sure 
> to coordinate with Timon Gehr. You'll want to steal all the 
> best ideas from the various implementations anyway. ;)
>
>> Do Dataflow analysis on the code that is to be ctfe'd so we 
>> can tell beforehand if we need to store state in the ctfe 
>> stack or not.
>>
>> Or baring proper data-flow analysis: RefCouting the variables 
>> on the ctfe-stack could also be a solution.
>
> I presume by "store state" you mean persisting objects beyond 
> the bounds of a single CTFE invocation? My first inclination 
> here would simply be to make all allocations from a new arena 
> each time CTFE is entered (can also re-use memory from prior 
> runs for that), do a deep-copy of the result (converting it to 
> full AST nodes, etc.), and then drop the entire arena. But 
> probably you have thought of (and discarded) this already.
>
>  — David

The current implementation stores persistent state for every ctfe 
incovation.
While caching nothing. Not even the compiled for of a function 
body.
Because it cannot relax purity.
Which is why a simple while-loop from 0 to 100_000_00 can crash 
dmd if executed at ctfe.

Your advice is a good one. I am happy to discuss with others!
There is no need to duplicate mental workload.