Skip Montanaro <skip@pobox.com>:
Guido> Yeah, but the runtime could offer a choice of data types -- for Guido> Python code the constants table would contain Python ints and Guido> strings etc., for Perl code it would contain Perl string-number Guido> objects. Maybe.
So I could give a code object generated by the Python compiler to the Perl runtime and get different results than if it was executed by the Python environment?
No, I don't think that's what Guido is saying. He and I are both imagining a *single* runtime, but with some type-specific opcodes that are generated only by Perl and some only generated by Python.
Perhaps it's time for Eric to chime in again and tell us what he really has in mind. I can't see the utility in having the same set of opcodes for the two languages if the semantics of running them under either environment aren't going to be the same. It seems like it would artificially constrain people working on the internals of both languages.
You're right. What I have in mind starts with a common opcode interpreter, perhaps based on the Python VM but with extended opcodes where Perl type semantics don't match, and a common callout mechanism to C-level runtime libraries linked to the opcode interpreter. In the conservative version of this vision, Perl and Python have different runtimes dynamically linked to an instance of the same opcode interpreter. Memory allocation/GC and scheduling/threading are handled inside the opcode interpreter but the OS and environment binding is (mostly) in the libraries. Things Python would bring to this party: our serious-cool GC, our C extension/embedding system (*much* nicer than XS). Things Perl would bring: blazingly fast regexps, taint, flexitypes, references. In the radical version, the Perl and Python runtimes merge and the differences in semantics are implemented by compiling different wrapper sequences of opcodes around the library callouts. At this point we're doing something competitive with Microsoft's CLR. My proposed work plan is: 1. Separate the Python VM from the Python compiler. Initially it's OK if they still communicate by hard linkage but that will change later. 2. Build the Parrot VM out from the Python VM by adding the minimum number of Perliferous opcodes. 3. Start building the Perl runtime on top of that, re-using as much of the Python runtime as possible to save effort. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Every election is a sort of advance auction sale of stolen goods. -- H.L. Mencken