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

[Eric S. Raymond]

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