Promoting to Complex

[Jonathan Worthington]

chromatic wrote:
> On Monday 27 September 2010 at 12:03, Jonathan Worthington wrote:
>> However, at this point I'd be very surprised if we're 
>> still using (in Rakudo) the Integer/Float PMCs for our Int/Num types 
>> after the meta-model replacement lands.
>>     
>
> What do Parrot's Int and Float PMCs need to be useful to Rakudo?
>
>   
Sorry, I shoulda been a bit more explicit on the reasoning. The issue 
isn't that they're not good enough, or that they need to change. Rather, 
it's that as the meta-model design has started to come together, I've 
mostly concluded they don't really fit in.

The Rakudo Int and Num objects need to be full-blown Perl 6-y objects. 
They are today, but we do that by wrapping Integer and Float PMCs up. 
(Sometimes we also create Integer and Float PMCs directly and stuff 
works because we evilly poke extra methods into global namespaces - 
something not sustainable in the long run). However, PMC inheritance 
today is really implemented as delegation - something not in itself a 
problem [1], but a bit too heavyweight for things as fundamental as Int 
and Num. The upshot today is that for an Int we have:

* The object PMC
* The RPA it references. Granted with some work this could go away in 
the current Object implementation.
* The Integer PMC

That's 3 gc-able objects, plus their storage space = 6 allocations. We 
can't go on like this.

While we could solve that in many ways, this wasn't the issue that 
actually tipped me (it's just helpful to describe the present before the 
future). Rather, it's the much more general issue is that I need to 
support inlining of types within the memory allocation of other types 
anyway (for the compact structs part of S09), and in that sense just 
having a native integer living in the object's chunk of memory is a 
de-generate, easy case of that (I expect it to fall out of exactly the 
same mechanism).

Thus, just by implementing what Perl 6 needs, I can have one Perl 6 
object allocated with a slot to store a native int/double - a big 
efficiency win on the allocations, not to mention we can stop polluting 
global namespaces. Furthermore, our implementation of e.g. infix:<+> 
today in Rakudo is e.g.

    pir::add__NNN($a, $b)

That is, we're not using the PMC's add v-tables at all, so it's not 
really even a painful change to make.

So really, this isn't a "the Float and Integer PMCs suck!" issue. It's 
simply that I'd have to go out of my way to use them, when a much more 
natural - and as a bonus, memory efficient - option is at hand.

Hope this makes some kinda sense. :-)

Thanks,

Jonathan