> What LispE proposes is to turn each instruction of the language into a derived class that exposes an eval method. Every class has its own override of eval. And since all these classes derive from a single mother class with an original and evocative name, Element, 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.
That's... a tree-walking interpreter. And IIRC the most overhead of it comes from traversing the tree itself, then from the overhead of invoking (virtual) eval() methods, and only then 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.
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.
Well, yes, it's an old way to represent ASTs: allocate them all sequentially from a huge arena (worked especially nicely for BCPL). Except the author actually uses their home-grown vecte<Element*> which, as far as I can tell, uses malloc/realloc. And there are several pointer indirections inside the liste/ITEM/LIST classes so... yeah.
> What LispE proposes is to turn each instruction of the language into a derived class that exposes an eval method. Every class has its own override of eval. And since all these classes derive from a single mother class with an original and evocative name, Element, 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.
That's... a tree-walking interpreter. And IIRC the most overhead of it comes from traversing the tree itself, then from the overhead of invoking (virtual) eval() methods, and only then 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.
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.
This doesn't move the needle there, at all.
So…you can transform it into a threaded interpreter?
This seems like a ton of LLM verbiage making two simple and very standard techniques sound artificially profound.
> If you build flattened a vector of them
Well, yes, it's an old way to represent ASTs: allocate them all sequentially from a huge arena (worked especially nicely for BCPL). Except the author actually uses their home-grown vecte<Element*> which, as far as I can tell, uses malloc/realloc. And there are several pointer indirections inside the liste/ITEM/LIST classes so... yeah.
What I find interesting is not only that this is a cool alternative Lisp but that it is developed by a Korean company called Naver[0].
[0]: https://github.com/naver
[1]: https://www.naver.com/
Lisp has had good native compilers for a long time, just use one of those.