Hello Edward, On Sat, Jan 18, 2003 at 10:40:33PM -0600, Edward K. Ream wrote:
This is an important theoretical result: the project can never fail due to the cost of compilation.
Yes, with good accounting algorithms we can save and restore some of the already-done work. The current Psyco is far from being able to do this cleanly, so I never really thought about it in depth, but it is certainly a desirable feature for a cleaner Psyco (like what I want to do in this project). In all cases I still think that there is some use for a fast-and-dirty compiler mode; for example, when compiling dynamically-constructed code that will change all the time.
Maybe that vm could be the intermediate code list of gcc? If compilation speed isn't important, the "compiler" would simply be the front end for gcc.
I am a bit afraid of what would have to be done to interface the "core" of GCC with Psyco, but this is mainly because I never digged to deeply into GCC. I am sure it can be done, and it would certainly be a great thing. I am sure that your experience in this domain would be most profitable :-)
provided that you (or rather Guido) is willing to expand the notion of the "byte code".
Yes, I think that we should try to unify the idea of function object vs code object in Python with other similar ideas used internally in CPython. For example, built-in function objects have a pointer to a PyMethodDef structure --- we find again the distinction between the "callable front-end" object and the "implementation-description" structure. Ideally, we should have only one all-purpose "function" object type, which holds things like argument names and default values, and any number of "implementation" object types, of which Python code objects would be one example, and PyMethodDef-like objects another. This would let us add other ways to implement functions, like Psyco-emitted machine code objects. Sometimes I wonder whether I should raise the question in python-dev. It seems to me that it helps in various places, e.g. in the help() mecanism which currently cannot guess the argument list for built-in functions. Well, I cannot see how to make it 100% compatible with existing code... Armin