21–30 of 42 posts
But can the interpreter interpret itself?
Earlier quoted context omitted.
It isn't a LISP :P
You don't need a language to be a LISP in order for them to be able to interpret themselves. There are several Java interpreters which can interpret themselves, for example.
Just in case anyone doesn't know, there's actually a real, live project that does this: https://pypy.org/ (Technically the base interpreter is a subset/restricted version of Python however). The reason this is done (my understanding), is that a the python source code for the base interpreter can be fed into a JIT generator, which produces a Python interpreter that can perform JIT optimizations.
> Technically the base interpreter is a subset/restricted version of Python however The base interpreter is written in a subset/restricted version of Python, but it's still Python. You can run Pypy as an interpreter on top of CPython or pypy. And IIRC the restrictions mostly have to do with static type inference so you're mostly limited in how dynamic/weird the program gets the other big limits being magic methods be…
Earlier quoted context omitted.
You don't need a language to be a LISP in order for them to be able to interpret themselves. There are several Java interpreters which can interpret themselves, for example.
You just need it to be a Lisp in order to do it in such a way that you get confused whether you're in the interpreted language or the host one.
It uses the host Python for attribute resolution (all code in getters and setters runs on the host), exception handling (which combines with the previous point to make some NameErrors impossible to catch) and even function calls (but all functions are wrapped so that their _call__ switches back to byterun as the interpreter).
Because of that confusion, byterun isn't very useful if you want to be really independent from the host interpreter; it's just too easy to escape from the VM. As a learning exercise however, it is helpful for understanding Python's innards at a level higher than C.
(2016), according to the HTTP headers: Last-Modified: Sat, 09 Jul 2016 12:15:59 GMT
I’m going to start having my server send Last-Modified: Mon, 20 Apr 3018 13:37:00 GMT Then we will see what people say when my stuff is posted :^) Then again my stuff probably wouldn’t get much attention to begin with. But if it did... People would have to admit that they are all living in the present whereas I was living in the future.
lamer ! :-)
Just in case anyone doesn't know, there's actually a real, live project that does this: https://pypy.org/ (Technically the base interpreter is a subset/restricted version of Python however). The reason this is done (my understanding), is that a the python source code for the base interpreter can be fed into a JIT generator, which produces a Python interpreter that can perform JIT optimizations.
cPython is the reference implementation, and has an explicity goal of being easier to understand. Yet, some part of it are quite obscure.
So here we are, with this beautiful blog post
Ouroboros would be a good icon for this project.
I found this code very useful. I've been spelunking in CPython and mostly I understand it, and can find my way around. But ceval.c is another beast entirely, being full of macros and gotos, not to mention being 5000 lines long. The interpreter loop starts here: https://github.com/python/cpython/blob/master/Python/ceval.c... So I appreciate seeing the algorithm laid out in Python. In particular it clarifies that there…
The interpreter loop has been simplified by moving the logic of unrolling the stack of blocks into the compiler. The compiler emits now explicit instructions for adjusting the stack of values and calling the cleaning up code for break, continue and return.
Removed opcodes BREAK_LOOP, CONTINUE_LOOP, SETUP_LOOP and SETUP_EXCEPT. Added new opcodes ROT_FOUR, BEGIN_FINALLY, CALL_FINALLY and POP_FINALLY. Changed the behavior of END_FINALLY and WITH_CLEANUP_START.
(Contributed by Mark Shannon, Antoine Pitrou and Serhiy Storchaka in bpo-17611.)