Battle-plan for CTFE

[Martin Nowak via Digitalmars-d-announce]

On 05/17/2016 12:42 PM, Don Clugston wrote:
> There's no need for grandiose plans, as if there is some
> almost-insurmountable problem to be solved. THIS IS NOT DIFFICULT. With
> the interface cleaned up, it is the well-studied problem of creating an
> interpreter. Everyone knows how to do this, it's been done thousands of
> times. The complete test suite is there for you. Someone just needs to
> do it.

Yes, exactly my words.

> I think I took the approach of using syntax trees about as far as it can
> go. It's possible, but it's really vile. Look at the code for doing
> assignments. Bleagh. The only thing in its favour is that originally it
> was the only implementation that was possible at all. Even the first,
> minimal step towards creating a ctfe backend -- introducing a
> syntax-tree-validation step -- simplified parts of the code immensely.

Yes, this
https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/dinterpret.d#L3418
is really ugly and complex, but you won't get rid of this inherent
complexity. The e2ir code for AssingExp looks almost the same
https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/e2ir.c#L2466.

> You might imagine that it's easier to work with syntax trees than to
> start from scratch but I'm certain that's not true. I'm pretty sure that
> the simplest approach is to use the simplest possible
> machine-independent bytecode that you can come up with. I had got to the
> point of starting that, but I just couldn't face doing it in C++.

All I'm saying is that interpreting the AST to generate bytecode is
going to be as complex as interpreting the AST directly, but then you
still a bytecode interpreter and later might still want a JIT.

Using dedicated value types during interpretation instead of recycling
the AST for that will also make the transitions clearer and get rid of
some of the lifetime complexities in the current code.

-Martin