On-topic: alternate Python implementations

[Paul Rubin]

Stefan Krah <stefan-usenet at bytereef.org> 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?  How would you handle garbage
collection?

C isn't so great for high-assurance stuff either, compared to (say) Ada.
People do use it in critical apps, but that's just because it is (or
anyway used to be) so ubiquitous.  I'm wondering what you mean about
verification tools, other than analyzers like Coverity that mainly check
for bugs that in a safer language would be caught by the compiler.
Compcert is not all that C-specific it has been adapted to compile a
Haskell-derived language (Habit).

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.

Finally, Python itself isn't all that well suited for compilation, given
its high dynamicity.  It will be interesting to see if the language
evolves due to PyPy.