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!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4