[Python-Dev] Common runtime sociology (original) (raw)

Simon Cozens simon@netthink.co.uk
Thu, 9 Aug 2001 11:12:30 -0700

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

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