At 07:15 PM 7/31/2001 -0400, Guido van Rossum wrote:
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.
Hm, the Python bytecode interpreter doesn't do the memory allocation/GC, and only does the scheduling/threading indirectly (by releasing and immediately reacquiring the global interpreter lock).
The Parrot interpreter does (or will at least, as there's not much code behind it yet) handle GC and intercept memory allocation, at least if you want to use managed memory. (Though that's only of interest to people who are writing C/C++/Fortran/Whatever extensions to the interpreter) GC & object destruction are going to be dealt with separately by the interpreter, FWIW. Which might not be much. As for threading, well, that's where things get interesting. Perl's tried it two ways (multiple threads in the same interpreter, and one thread per interpreter, with cloned interpreters) both of which aren't very good. And the global lock thing's not that keen either. The plan for parrot is to allow multiple interpreters to run simultaneously, with shared data protected on access time. (And *only* shared data protected, so there's no penalty to access non-shared data) Along with a scheme to allow only partial (or no) visibility of the spawning thread's variables. We plan on basing the secure sandbox scheme around this as well.
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.
I'm not sure I want references,
You certainly don't have to have them. The parser doesn't have to necessarily expose all the features of the interpreter. What you'd expose to the programmer would depend on the language grammar--if you can't write valid Python code to take references, well, you don't get them. :)
and I don't know what flexitypes are.
I presume this is perl's "I'll make it any type I darned well need" basic scalar, or possibly it's auto-resizing arrays and hashes. Neither of which you have to have either. Since that behaviour's a function of the type of a variable, we'd just not give python variables perl variable types. (Or the vtables that go with them) Now, what happens when a Python routine is passed a perl variable is an interesting question. Personally I'd presume that it Did The Right Thing, but I'm not 100% sure what that is. Probably maintain its core behavior. (So if I passed in a Magic Morphing Perl Scalar to a Python routine that needed an integer value, it'd get one, but if I tried to use a Python integer in string context in a perl sub, I'd get yelled at. (Assuming that's the correct behaviour, of course. If not, well, it'd do something else)) Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk