Rocco Moretti wrote: ...
My plan was "simply" to take the CPython code and convert it into Python code, minimizing the use of "high level" features like lambda, generators, etc., so that a small core could easily be hand compiled into the language du jour. Eventually, a reduced dialect of Python might be employed for the core (interpreter loop and basic objects) such that a simple compiler could be built for it.
Very true. ...
Unfortunately, it was *extremely* unclear where PyPython ended and the host system began. In my final incarnation, the PyPython objects with external visibility were referenced from a global definition file (a'la python.h), where they were simply imported wholesale from __builtins__.
It is one of my fears when rewriting Python in Python: How often will I fail to recognize in which system I am? There was a two-part TV film like "world at the wire" in Germany, late 70's, where the level of simulation also was not always clear :-)
But the problem which stymied me was the issue of what to do with Exceptions. I discarded the concept of copying the "return Null" technique of CPython - having to check every return value for an error condition seems so unpythonic.
It does seem so if you have to write that crap by hand. When generating code, this is no issue at all. I wasn't sure for myself about this problem. Then I read Armin's long reply to everything, and I found one thing of his generated-c-approach appealing: Everything is turned back into generated C, and there is no question about exceptions: Surely they would be built like before. Now, why do we have a problem with it in an interpiler that does not create C code? I think we do lack experience. ...
I agree with using cross compilers in the bootstrap proceedure and with being "stackless" - two features I was going to apply. One additional thing that came about as a direct result of Python's lack of a switch statement: I replaced the switch statement with an array of references to functions implementing the opcodes.
This is most natural if you don't have a case construct. If I ever whished to add such a thing, then for this project :-)
(I was > going for clarity over speed) One offshoot of this is the potential to have multiple opcode schemes in the same interpreter. (Like Python 1.5.2 and Python 2.2 - or better yet, Python and Java)
Absolutely, this can be done if it makes enough sense.
How does that work with parameter/return value passing and potential psyco optimization? Don't know - didn't get that far.
After Armin's recent post, it seems to be true that Psyco will get a complete rewrite, with a whole lot of new ideas. Armin seems to be eager to try different object layouts as well, with/without refcounts, with classical GC, ..., so I believe the new, Python-based Pysco will be very capable.
I might not make the sprint, but I'd be glad to help as I can, Rocco Moretti
There will be a second sprint, right before EuroPython. At least, Guido proposed that, probably enough to make it doubtlessly happen. ciao - chris