Python compilers?

[Yermat]

Heiko Wundram wrote:
> [...]
> 
> In Python this isn't true. Python, instead of LISP, is "completely" dynamic, 
> meaning that it's pretty impossible to do type-inference for each function 
> that is called (even checking types isn't possible). E.g. how do you expect 
> type-inference to work with the pickle module? string -> something/Error 
> would be the best description what pickle does. For the function which calls 
> pickle, do you want to create versions for each possible output of Pickle? 
> Which outputs of Pickle are possible? (depends on the loaded modules, which 
> can be loaded at runtime) There is no (sane) way to create machine-code which 
> calls into the appropriate (low-level) Python-runtime functions (such as 
> Py_List*, Py_Dict*, etc.) for such a method, at least not at compile-time.
> 
> At runtime, this is possible. See what psyco does. There's a nice presentation 
> on the psyco-website which explains what it does, and I guess you'll 
> understand when you see that why writing a "compiler" for Python is pretty 
> impossible.

That is here where you are wrong !
It can be known at compile time if you know every modules that will be 
imported. That is called "closed environment".

If it is the case, you would be able to compile a program even if you 
would not be allowed to do incremental compilation... That just mean 
that you will need to recompile everything each time you modified something.

The demonstration is quite easy:
In a "closed environment" there is a finite number of classes. So you 
just have to create as much specialized functions as classes. Then where 
you can infere type, call directly the good function. Elsewhere, just 
call a runtime dispatcher. In fact, it is already used in some languages 
like Eiffel with certain optimizations.

The problem is that many python programs are not "closed" at 
compile-time, ie they import or eval stuff only known at run-time.

impossible n'est pas français ;-)

-- 
Yermat