> What LispE proposes is to turn each instruction of the language into a derived class that exposes an <i>eval</i> method. <i>Every class has its own override of eval</i>. And since <i>all these classes</i> derive from a single mother class with an original and evocative name, <i>Element</i>, you can build a C++ vector that holds them all. And that is where the miracle happens: the AST is kept alive, but each node is an object that can be optimized to the hilt with the full C++ arsenal.<p>That's... a tree-walking interpreter. And IIRC the most overhead of it comes from traversing the tree itself, <i>then</i> from the overhead of invoking (virtual) eval() methods, and only <i>then</i> from whatever inefficiencies are inside of those tiny eval() implementations.
If you build flattened a vector of them (as they argue), it can approach a byte code interpreter, though it won't be a very dense vector, if it holds "pointers" (that you need to chase) to the instructions instead of the instructions themselves.<p>A lot of the slowness of interpreters (and why JITs work) comes from the fact that you're executing (and trying to predict) the interpreter's branches - not the branches in the interpreted code.<p>This doesn't move the needle there, at all.