On-topic: alternate Python implementations

[Stefan Behnel]

Paul Rubin, 04.08.2012 17:59:
> Stefan Krah writes:
>> In the free software world, apparently many people like C. C is also
>> quite popular in the zero-fault software world: Several verification
>> tools do exist and Leroy et al. are writing a certified compiler for
>> C to plug the hole between the verified source code and the generated
>> assembly.
> 
> C is pretty poor as a compiler target: how would you translate Python
> generators into C, for example?

Depends. If you have CPython available, that'd be a straight forward
extension type. Otherwise, I guess you'd either have a class for them in
C++ or a struct in C. Not exactly complex.

For the yielding, you can use labels and goto. Given that you generate the
code, that's pretty straight forward as well.


> How would you handle garbage collection?

CPython does it automatically for us at least. Lacking that, you'd use one
of the available garbage collection implementations, or provide none at all.


> Haskell doesn't sound all that great as a translation target for Python
> either, unfortunately, because its execution semantics are so different.
> GHC is a very powerful compiler but it was made to compile Haskell code
> that people actually write, and may do less good of a job with compiler
> output from an imperative language like Python.  Compiling Python to
> Scheme and then using a Scheme compiler might be a more natural fit.
> But, compiling to Haskell was probably pretty convenient for that
> particular project.

You'd have some kind of emulation layer that does most of the translation
at runtime. That's why I said that you shouldn't expect too much of a
performance gain from what the platform gives you for the underlying
implementation. It can optimise the emulator, but it won't see enough of
the Python code to make anything efficient out of it. Jython is an example
for that.


> Finally, Python itself isn't all that well suited for compilation, given
> its high dynamicity.

You can get pretty far with static code analysis, optimistic optimisations
and code specialisation. We've decided against whole program analysis in
Cython not only for compiler complexity reasons but also because it would
let the normal compilation time explode for gains that you can much easier
get by manual optimisation. Obviously, optimising JIT compilers can do much
more here (because they actually have to do less), although they won't
always be able to figure out the right thing to do either. That's where
manual optimisation wins again.

Stefan