It's interesting seeing all these languages built on top of the Python VM, when the Python VM is one of the slowest.

What are "all these languages?" This is the first one I've seen. This one doesn't even seem to be meant for practical use, rather a learning exercise by the author.

Pixie (kind of Lisp) mentioned a few days ago was built on RPython, and Hy (similar kind of Lisp) is built on Python's VM.

While Pixie is implemented in RPython, Pixie code does not run on the Python VM. You can run the Pixie _interpreter_ in the Python VM, since it is valid Python code, but that is markedly different than compiling a language to Python bytecodes.

What does Pixie itself actually run on then?

That depends on how you run Pixie. There are 2 possible cases.

1. Run Pixie atop the Python VM: this is quite slow as there are 2 levels of interpretation. This is mostly used for testing.

2. As a standalone binary: The RPython language includes a translator which targets C. The generated code is reasonably fast (I think the PyPy interpreter without the JIT is within a factor of 2 the CPython VM). The translator is also responsible for generating the JIT compiler for your interpreter, so a well written interpreter can indeed be quite fast, post translation.

Well Hy is just an alternate syntax, wouldn't really call it another language as the semantics are the same.

Because the author wrote this as a fun exercise in what seems to be one of his favourite languages for testing a library he wrote (libpy)?

Comments today....

It would be interesting to see how well PyPy optimizes the code generated by the Phorth compiler, but it looks like this needs some hacks via the CPython C API to work. Even if it could be made to work, I doubt the PyPy JIT would like some of the odd things Phorth does to the internal interpreter state.

I don't think that it will ever work on PyPy. The data stored in the `co_code` field is a super set of the instructions python understands. The `co_code` data starts with a prelude which is the repl and builtin words, then there is a large chunk of unallocated data (starting as `NOP`) followed by a suffix except block. Once you define a new word from within the interpreted phorth code you will write the address of each word called into the code object at the HERE marker, which starts at the beginning of the `NOP` segment. Basically if you write a word like: `: square dup * ;` then you will be writing the address of `dup` over the first two `NOP`s, then the address of `*` over the next two `NOP`s, finally you write the address of a return procedure over the next two `NOP`s after that. These are not valid instructions for the interpreter loop but the normal interpreter never hits them.

Fortunately, computers are fast enough that VM speed isn't the only thing to care about.

Wouldn't the pronunciation cause confusion?

With a username like "llllllllll" I don't think pronunciation is his concern.