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

[Dan Sugalski]

[Eric, could you forward this to python-dev if it doesn't show of its own 
accord? I'm not yet subscribed, so I don't know if it'll make it]

I should start with an apology for not being on python-dev when this 
started. Do please Cc me on anything, as I've not gotten on yet. (My 
subscription's caught in the mail, I guess... :)

At 04:14 AM 7/31/2001 -0400, Eric S. Raymond wrote:
>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.

Odds are there won't even be a different set of opcodes. (Barring the 
possibility of the optimizer being able to *know* that an operation is 
guaranteed to be integer or float, and thus using special-purpose opcodes. 
And that's really an optimization, not a set of language-specific opcodes) 
The behaviour of data is governed by the data itself, so Python variables 
would have Python vtables attached to them guaranteeing Python behaviour, 
while perl ones would have perl vtables guaranteeing perl behaviour.

This was covered, more or less, by the chunks of the internals talk I 
didn't get to. Slides, for the interested, are at 
http://dev.perl.org/perl6/talks/. I'm not sure if there's enough info on 
the slides themselves to be clear--they were written to be talked around.

> > 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.

I've snipped the rest here.

I don't think Parrot will be built off the Python interpreter. This isn't 
out of any NIH feelings or anything--I'm obligated to make it work for 
Perl, as that's the primary point. If we can make Python a primary point 
too that's keen, and something I *want*, but I do need to keep focused on perl.

Having said that, what I'm doing is stepping back from perl and trying, 
wherever possible, to make the runtime generic. If there's no reason to be 
perl specific I'm not, and so far that's not been a problem. (It actually 
makes life easier in a lot of ways, since we can then delegate the decision 
on how things are done to the variables involved, providing a default set 
of behaviours which the parser will end up determining anyway)

On some things I think I'm being a bit more vicious than, say, Python is by 
default. (For example, if extension code wants to hold on to a variable 
across a GC boundary it had darned well better register that fact with the 
interpreter, or it's going to find itself with trash) I'm not sure about 
the extension mechanism in general--I've not had a chance to look too 
closely at what Python does now, but I don't doubt that, at the C level, 
the differences between the languages will be pretty trivial and easily 
abstractable. Seeing what you folks have is on the list 'o things to do--I 
may well steal from it wholesale. :)

I expect there's a bunch of stuff I'm missing here, so if anyone wants to 
peg me with questions, go for it. (Cc me if they're going to the dev list 
please, at least until I'm sure I'm on) I really would like to see Parrot 
as a viable back end for Python--I think the joint development resources we 
could muster (possibly with the Ruby folks as well) could get us a VM for 
dynamically typed languages to rival the JVM/.NET for statically typed ones.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk