> > 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). >
I see. ¿But what's the rational to have Bigints / Bigfloat be native types instead of PMCs? > > 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. > ¿What about arrays, hashes, etc.? How do we expect arr1 + arr2 to concatenate the two lists when called in python but not in perl. Eithere we define an intermediate type for everything (which can be tricky for user-defined classes that inherit core types, and slow if inter-language calls are frequent) or have some other mechanism to implement the various meaning of operators. It looks to me that a + cannot be directly translated to pmc->vtable->add, since in that particular language + can mean anything different (or additionally to) mathematical additon. We should separate the definition of vtable methods (that in my humble opinion should have a clear, language-independent, meaning, from the actual language-dependent interpretation of operators, casting between types, dwiminery, etc.. For instance, we should not have arrays PMC evualate to its length automagically when called in scalar context, but have a separate length method. Then, perl opcodes that require scalar context can call this method if it turns out that its PMC argument is an array. This would allow to have the core PMC types be language-independent, and thus they will be able to pass freely between languages. On the other hand, we'll need language-dependent opcodes, but i guess this will happen anyway. The only thing required is to have the compiler and the opcodes be a bit smarter. In other words, in my humble opinion (which is a not very qualified one :) it is a bad idea to put the language-dependent behaviour in the PMCs because PMCs hold user's data, and data should freely travel the language boundaries. The right place to put language-dependent behaviour is in the opcode, which is generated by a language-aware compilation of this particular fragment of code. -angel
