[Python-Dev] Parrot -- should life imitate satire?

[Dan Sugalski]

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