11–20 of 57 posts
Earlier quoted context omitted.
PyPy is python implemented in python. It is fast.
PyPy is python implemented in RPython, which is technically a python subset. It's so restricted it might as well be a different language though.
Just wondering why you stopped there? Why not a python interpreter for a python interpreter for python ?
Earlier quoted context omitted.
PyPy is python implemented in RPython, which is technically a python subset. It's so restricted it might as well be a different language though.
It is restricted in a way that you would restrict yourself to write high speed software in most languages, and I found it is not that restrictive compared to C that you would have to use if you were to write a fast Python library.
See also https://github.com/nedbat/byterun and https://github.com/rocky/x-python
And, in some ways, PyPy. I still think it is the sanest way to implement Python. It makes me sad that I have to write C to make any meaningful changes to Python. Same goes for ruby. Rubinius was such a nice project. Hacking on schemes and lisps made me realize how much more fun it is when the language is implemented in the language itself. It also makes sure you have the right abstractions for solving a bunch of real…
Shedskin is very nearly Python compatible, one could say it is an implementation of Python.
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.
Earlier quoted context omitted.
PyPy is python implemented in python. It is fast.
PyPy is python implemented in RPython, which is technically a python subset. It's so restricted it might as well be a different language though.
So it can just run under CPython? If so, then that isn't too misleading.