[BoppreH]

> Byterun is a Python interpreter written in Python. This may strike you as odd, but it's no more odd than writing a C compiler in C.

I'm not so sure. The difference between a self-hosted compiler and a circular interpreter is that the compiler has a binary artifact that you can store.

With an interpreter, you still need some binary to run your interpreter, which will probably be CPython, making the new interpreter redundant. And if you add a language feature to the custom interpreter, and you want to use that feature in the interpreter itself, you need to run the whole chain at runtime: CPython -> Old Interpreter That Understand New Feature -> New Interpreter That Uses New Feature -> Target Program. And the chain only gets longer, each iteration exponentially slower.

Meanwhile with a self-hosted compiler, each iteration is "cached" in the form a compiled binary. The chain is only in the history of the binary, not part of the runtime.

---

Edit since this is now a top comment: I'm not complaining about the project! Interpreters are cool, and this is genuinely useful for learning and experimentation. It's also nice to demystify our tools.

[gwerbin]

PyPy handled this by implementing PyPy in a restricted minimal subset of Python that they called RPython, and that seemed to work out well for them.

[mikepurvis]

I was never a user of PyPy but I really appreciated the (successful) effort to cleanly extract from Python a layer that of essential primitives upon which the rest of the language's features and sugar could be implemented.

It's more than just what is syntax or a language feature, for example RPython provides nts classes, but only very limited multiple inheritance; all the MRO stuff is implemented using RPython for PyPy itself.

[paulddraper]

The key difference is that RPython is actually a compiled language.

I.e. PyPy DOESN'T have an interpreter written in an interpreted language.

[SJC_Hacker]

This is the case only if the new interpreter does not simply include the layer that the old interpreter has for translating bytecode to native instructions. Once you have that, you can simply bootstrap any new interpreters from previous ones. Even in the case of supporting new architectures, you can still work at the Python level to produce the necessary binary, although the initial build would have to be done on an already supported architechture.

[direwolf20]

Interpreters don't translate bytecode to native instructions.

[SJC_Hacker]

The usual understanding of "interpreter" in a CS context is program that executes source code directly without a compilation step. However the binary that translates an intermediate bytecode to native machine code is at least sometimes called a "bytecode interpreter".

https://doc.pypy.org/en/latest/interpreter.html

[ghusbands]

This is still incorrect. A bytecode interpreter, as its name indicates, interprets a bytecode. Typically, compiling a bytecode to native machine code is the work of a JIT compiler.

[genxy]

They do now https://github.com/bytecodealliance/weval

[ghusbands]

That's a partial evaluator, not an interpreter, and it converts an interpreter into compiler, which are different things.

[genxy]

> Interpreters don't translate bytecode to native instructions.

> That's a partial evaluator, not an interpreter, and it converts an interpreter into compiler, which are different things.

https://old.reddit.com/r/Compilers/comments/1sm90x5/retrofit...

[ghusbands]

Yes, that's another great example of the same kind of thing - creating a JIT from an interpreter. It remains true that interpreters do not directly generate machine code.