Battle-plan for CTFE

[Martin Nowak via Digitalmars-d-announce]

On 05/18/2016 07:50 PM, Stefan Koch wrote:
> Indeed.
> 
> I am currently designing an IR to feed into the CTFE Evaluator.
> I am aware that this could potentially make it harder to get things
> merged since DMD already has the glue-layer.

As a compat layer between different interpreters or as a compat layer
between all backends? Adding another translation might not be
acceptable, at least for real backends.

> However I do think that the benefits outweigh the drawbacks by far.
> Especially when one looks at the possibility to eventually plug llvm or
> the gcc-jit in.

Indeed, but it heavily increases the chance that your project lands on
the unfinished D project pile.

> My CTFE needs are rather heavy weight. So I will go for a solution that
> can support this.
> I believe the pressure on CTFE performance will increase as soon as the
> preformance increases. Since this will enable much more things.
> I.E. running a query optimizer at compile-time.

That might be true, but scripting languages are still fast enough to be
used everywhere. You won't need native CTFE performance for it to be an
enabling technique.

-Martin