[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