Battle-plan for CTFE

David Nadlinger via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Mon May 9 11:19:53 PDT 2016


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


More information about the Digitalmars-d-announce mailing list