begin quote from Angel Faus: > I see. ?But what's the rational to have Bigints / Bigfloat be native types > instead of PMCs?
They're useful and predictable. And also, you may want to automatically promote integers to bigints; you probably don't want to automatically promote integers to complex types. :) > ?What about arrays, hashes, etc.? How do we expect arr1 + arr2 to > concatenate the two lists when called in python but not in perl. Because Arr1 in PythonArray in Python and PerlArray in Perl, and they'll have different "add" vtable methods. > 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. The fact that in a given language + can mean something other than mathematical addition is *precisely* why it must translate to pmc->vtable->add. Different languages provide different implements of the vtable method. You'd expect JavascriptString's add operator to do something slightly different from PerlInteger's. > 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.. Of course, if the Javascript compiler wants to compile + to "concat" instead, that that's up to it. This gives us a nice flexibility in implementation. > 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. I think I prefer the way we're currently doing it; it gives us a consistency which means that we can get a scalar value from PerlInteger, PerlFloat, PerlArray and PerlHash and the same vtable method will do the right thing. > 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. Right. > 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. I'm afraid I have to disagree very violently with you on this one. -- "The best index to a person's character is a) how he treats people who can't do him any good and b) how he treats people who can't fight back." -- Abigail Van Buren
