Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 18/05/2016 9:01 AM, Martin Nowak wrote:
>
> 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.
>


IMO this is a different problem, that AssignExp is stupidly complex and 
needs to be split up.

>> 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.

The bytecode generator and bytecode interpreter can be debugged (and 
tested!) independently.  So the total amount of code will increase but 
the components themselves will be better isolated and easier to work with.

I don't think a possible future need for a JIT is a good reason to avoid 
an bytecode interpreter.  A large part of the work of adding a new (JIT) 
backend is pinning down the semantics, and adding a bytecode interpreter 
will certainly help to do that.

>
> 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.
>

Meh, sure.  But this feels just as difficult as switching to a simple 
bytecode, without all the benefits.