On Sun, 3 Feb 2002, Angel Faus wrote: > I. Missing methods in parrot: > > The are many vtable methods in python not present in parrot. Some of the > ones I would expect to really be needed are: > > * divmod # integer division > * power > * absolute > * invert > * compare
Yes, we are short a few vtable methods. We probably want one for everything that we can currently overload in perl5 (albeit from perl space). > They've got also a bunch of methods for things like calling builtin methods, > getting and setting object attributes, and so on. But I guess these ones > should better stay out until that part of the design is more advanced. I imagine these will translate down to simple subroutine calls in parrot or calls to specialised C code that implements them. > III. A different solution for coercion > > In Parrot, we currently define a new family of methods for each type of > number (or string btw). So we have: > > void add (PMC * value, PMC* dest) > void add_int (INTVAL value, PMC* dest) > void add_bigint (BIGINT value, PMC* dest) > void add_float (FLOATVAL value, PMC* dest) > void add_bigfloat (BIGFLOAT value, PMC* dest) > void add_same (PMC * value, PMC* dest) > If we wanted to a add a new number or string type (for instance a Complex > type), then we should create a new family of add_complex, subtract_complex, > etc.. methods, and implement them on each PMC class. These methods are provided so that we can play with "native" types in our bytecode then send them to our pmc, as otherwise every constant in our code would have to be a PMC, which is a little excessive. Things like a complex number will be represented by either a PMC class (very likely for complex numbers) or a language level overloaded class (like a Quantum::Entanglement). > Additionally, in the specific Parrot case (where we want to execute code of > different programming languages) I would say that this is the only way to do > the right thing, because the same mathematical operation can require > different coercion polices for different languages. (Think on perl, who Thus we have PerlInts, PythonInts etc... In general these will inherit from default.pmc except where they do something different. > So it looks to me that coercion doesn't belong to the object domain, but to > the language domain, (since a number born in perl could easily end up in > python) and thus its code shouldn't live in the vtable but in the opcode (or Passing things between languages will need a well defined type coercion mechanism. In general I expect that a PerlString will be turned into a string constant then loaded into a PythonString by code that knows what it's doing. After all, we need to do something simillar when passing SVs into C code at the moment, and I'm sure Inline::* will provide not only endless amusement but also some useful advice on this. Alex Gough -- It is easier -- even quicker, once you have the habit -- to say "In my opinion it is not an unjustifiable assumption that" than to say "I think".
