Open masak opened 6 years ago
I don't think it has occurred to me until now, but a natural part of landing a genuine separate interpreter would be to also separate the execution logic in the .run
and .eval
methods from the Q
types they're in. (An idea previously toyed with in #246.)
Of course, as Writing Solid Code points out, it's very useful to have two separate implementations of a thing, taking two separate approaches. Any discrepancy between them points, almost by definition, to something interesting. So we should make full use of that. The current logic should be kept, but demoted to legacy status and available through a --backend
option.
I have the bytecode interpreter outlined here in this gist.
As for implementation language, I think Perl 6 makes sense for a first implementation. Out of scope for this issue: a 007 implementation (for bootstrapping), and a D implementation (for speed).
It might be easier for a first version to work off a textual input format. But the final version should be using bytecode.
If this goes well, I'd like for the bytecode interpreter to replace the current AST interpreter in
Runtime.pm6
as our default backend.