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

[Thomas Wouters]

On Tue, Jul 31, 2001 at 01:31:01PM -0600, Nathan Torkington wrote:
> Guido van Rossum writes:
> > Yeah, but the runtime could offer a choice of data types -- for Python
> > code the constants table would contain Python ints and strings etc., for
> > Perl code it would contain Perl string-number objects.  Maybe.

> A perl6 value have a vtable, essentially an array of function pointers
> which comprises the standard operations on that value.  I talked to
> Dan (the perl6 internals guy, dan@sidhe.org) about an impedence
> mismatch between Perl and Python data types, and he pointed out that
> you can have Perl values and Python values, each with their own
> semantics, simply by having separate vtables (and thus separate
> functions to implement the behaviour of those types).  Code can work
> with either type because the type carries around (in its vtable) the
> knowledge of how it should behave.

Python objects all have vtables too (though they're structs, not arrays...
I'm not sure why you'd use arrays; check the way Python uses them, you can
do just about anything you want with them, including growing them without
breaking binary compatibility, due to the fact Python never memmoves/copies)
but that wouldn't solve the problem. The problem isn't that the VM wouldn't
know what to do with the various types -- it's absolutely problem to make a
Python object that behaves like a Perl scalar, or a Perl hash, including the
auto-converting bits...

The problem is that we'd end up with two different sets of types...
Dicts/hashes could be merged, though Perl6 will have to decide if it still
wants to auto-stringify the keys (Python dicts can hold any hashable object
as key) and arrays could possibly be too, but scalars are a different type.
You basically lose the interchangability benifit if Perl6 code all works
with the 'Scalar' type, but Python code just uses the distinct
int/string/class-instance...

But now that I think about it, this might not be a big problem after all. I
assume Perl6 will always convert to fit the operation, like Perl5 does.
It'll just have to learn to handle a few more objects, and most notably
user-defined types and extension types. Python C code already does things
like 'PyObject_ToInt' to convert a Python value to a C value it can work
with, or just uses the PyObject_<operation> (or PyMapping_<operation>, etc)
API to manipulate objects. Python code wouldn't notice the difference unless
it did type checks, and the Perl6 types could be made siblings of the Python
types to make it pass those, too. We already have the 8-bit and 16-bit
strings.

About the only *real* problem I see with that is getting the whole farm of
mexican jumping beans to figure-skate in unison... It'll be an interesting
experience, with a lot of slippery falls and just-in-time recovering... not
to mention quite a bit of ego-massaging :-) But I think it's just a manner
of typing code and taking the time, and forget about optimizing the code the
first couple of years.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!