[Python-Dev] Common runtime sociology

[Simon Cozens]

On Wed, Aug 08, 2001 at 09:57:50PM -0400, Dan Sugalski wrote:
> I think it's possible for things to be done otherwise, but it puts a heavy 
> burden on the implementation group to be actively engaged with the language 
> groups and be as impartial as can be managed. 

I think technically, it's very easy; Python people might understand the
parallel that their interpeter per se isn't too concerned with the
behaviour of individual types - all the type-specific behaviour is
defined in the various vtables for the types. (Object/*.[ch]) 

It is, you know, possible to add Object/PerlVar.c to have an object
behave like a Perl variable. And since you can specialise the hell out
of what you do in Object/PerlVar.c while the main loop of the
interpreter is very generic, you can make Perl types run as fast as
Python ones or better. 

(The more I look at Python's VM, the more it seems to have many of the
ideas that we want in it...)

So *in* *a* *very* *restricted* sense*, I agree with Eric's proposal
that we should look at using the Python interpreter as a base for Parrot
- in design, if not in actual code. (Especially since we'll want to
change it to a register model.) There are a few things I've identified
that we should change from the way Python does stuff, (notably that we
should make types mutable, and we should try and see if we can remove
the "Type object" layer of abstraction, since that indirection slows us
down) but the core of what you've got looks really, really useful.

Now I've put myself on the line, it's time for Dan to come over and
correct me. ("Ouch!") :)

> You almost need to take the implementation group that starts this and
> pry them loose to be an entity in and of themselves, separate from the
> original language group. (FWIW, this is part of my Master Plan. Dunno
> if it's part of Simon's)
 
I was going to suggest a separate Parrot project, but thought that might
be going too far. Glad we're on the same wavelength.

Simon