intertwingly

One of the name for Python running on Parrot is Pyrate.  In order to support the whole language, the Python compiler itself needs to run on Parrot.

The current Python compiler is written in C.  The Iron Python Compiler is written in C#.  The Jython Compiler is written in Java.

The approach used for the pie-thon involved mdis.py to compile a Python source and disassemble the resulting Python bytecode, and pie-thon.pl to translate the equivalent of Python assembler language to PIR.  This is then compiled into Parrot Byte Code, which is what is ultimately executed.

This is good for a proof of concept, but in the opinion of Leopold Toetsch A real implementation of a compiler should use the AST to produce Parrot bytecode.  The overall approach would look something like this [adapted from Him Hugunin's presentation on Iron Python]:

Michal Sabren's pirate (currently stalled) goes directly from Python AST to PIR, which would still need to be compiled.

Loepold took Mical's approach and created ast2past.py which compiles source to Python's AST, and then converts it to Parrot's AST, which as near as I can tell, is unimplemented.  I'm not even clear on what a Virtual Machine's AST is.

Potential Approach

It seems to me that one should settle on an interface to Parrot, and work backwards from that point in Python.  At the moment, the PIR interface seems the most viable (though I freely admit that may be due to my ignorance at this point).  If so, the first effort would be to upgrade pirate to produce PIR equivalent to that which is produced by pie-thon, using the Python tests to guide development.

The result would still depend on the Python compiler (written in C).  In order to host this on Parrot, a Python Parser would need to be written.  It could leverage the existing tokenizer as a Python Scanner.

Ultimately, when self hosted, the need for IL in any textual form could be dispensed with.