Last year (IPC7,) I thought I was going to surprise the Python community by presenting a prototype Python to C translator. Little did I know, I was only one of three people who announced such a product. This year (IPC8,) in the interest of keeping people up to date, there was a two hour session that hosted the developers of these prototypes. The only system left standing is now complete and under beta test. Bill Tutt and Greg Stein cowrote Python2C, which they have been continuing to work on at (http://www.mudlib.org/~rassilon/p2c/). The other player is John Aycock. John declared he would look into run time type instrumentation, which I think should end up forming some sort of a JIT for Python. He lives at: (http://gulf.uvic.ca/~aycock/)
Since I don't have much time for such things, I intend to look into integration of PyFront's dataflow analysis engine and Python2C. I reported such, but then digressed into Basil land. I pitched this stuff in two parts: where I have been, and where I'd like to go.
WHERE I'VE BEEN
Now, I originally began work as an intern on GRAD:
GRAD stands for Grammar-based Rapid Application Development. My mentor, Charlie Fly, brought me on to assist with a C++ parser he was working on. Charlie was building a C++ parser to automatically generate bindings for C++ code into Python. However, the important idea was: give us a programming language grammar, and we can build an automated Python binding. Such a system would lower the cost of moving to a rapid application development platform, such as Python, when a large code base of legacy software was already in place.
When I came on, I helped to test the GRAD parser, and because there were no fine grain line coverage tools, I wrote one for Python. From my initial prototype came GRAD/Paths. The ultimate objective of Paths was to build static code slices and solve these slices for unit test vectors. These would be used to obtain full code coverage for any language available to GRAD (and therefore my prototype handled C, C++, and Python.) I gave a short talk about this at IPC6:
Now at the end of developing the first proof of concept version of Paths there were heated discussions about compiling Python on the comp.lang.python newsgroup. It seemed to me that since I was taking C/C++ and converting it to an abstract dataflow domain, and taking Python and converting it to an abstract dataflow domain, why couldn't I just reverse the C/C++ to dataflow mapping, and generate C/C++ from Python source? I codenamed this project Basil, since Basil the Killer Sheep sprang from Monty Python (where Python really gets its name,) and I was unsure if I could keep the semantics true to Guido's original language. I pondered on this for a while, and the topics I imagined Basil covering extended to building a parsing infrastructure that supported building arbitrary legacy code translators and modeling tools. Basil would be the rapid GRAD development environment.
Anyway, using lessons learned in GRAD and Paths, I set out to compile Python. The result was success: I was able to generate C from Python source in less than a month. I was able to handle non-trivial code (such as a three dimensional cellular automata demo) a month after that. I wrote a paper, and it was accepted for presentation at IPC7:
WHERE I AM GOING
As mentioned above, the scope of what I am calling the Basil project has been greatly expanded from its roots as a Python compiler. The technology that I am seeking is "language transcendant computing," or basically an evironment where one is able to work with, code in, and integrate any computer language, even one they designed. In order to build such an environment, I am proposing to create a platform of tools that will allow rapid prototyping of three elements: