Battle-plan for CTFE

[Martin Nowak via Digitalmars-d-announce]

On 05/18/2016 04:59 PM, Daniel Murphy wrote:
> 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.

It's simpler to debug an AST interpreter working with a stack of
high-level values, than it is to debug a bytecode interpreter where lots
of context has been converted to jumping goto code.

Just to illustrate my point, here are an AST and a BC interpreter for
very simplistic functional language I wrote recently. The later one
still missing the actual interpretation.
https://github.com/MartinNowak/CC1/commit/ed28b8966de86e7449f93ce4e4cf7aed3082180b
https://github.com/MartinNowak/CC1/commit/899e67cf7038050b86eed533c9165bd2ba06e609

There is nothing simpler about a BC interpreter. Instead you have to
deal with converting control flow and computing addressing.

The debugging metaphor would be comparing a program that only uses
pointer arithmetic against one that is memory safe, the former can
randomly write everywhere from anywhere, the latter could use the wrong
reference.

> I don't think a possible future need for a JIT is a good reason to avoid
> an bytecode interpreter.

It's a very good reason, b/c once you work on JIT, there is no benefit
for BC left, e.g. all the extra work for nothing.
That said, I doubt we'll need a JIT anytime soon.

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

The semantic problem is already solved, in a file called interpret.d by
sth. that's an AST interpreter, that just happens to use the wrong value
structures and leaks memory. Converting that to BC will be quite
difficult, cleaning it up and changing it to use a better stack and
deterministic memory management is rather straightforward.

Last but not least, don't forget that we have the same situation since
over 3 years already. It has always been similarly easy to write a
better interpreter, it just never happened b/c the ambitions never
matched the available resources.

-Martin