Re: Patches that will come...

On Wed, Sep 01, 2004 at 11:16:41PM +0100, Tim Bunce wrote:

> It maybe that the gains achieved from implementing Perl5 types as PMCs,
> and other planned changes, may be sufficient to raise performance to the
> point where the presumed gains from removing ref-counting are less important.

Were the goals of ponie ever written down?
My impression was that performance (and improving it) wasn't actually
a priority. The principle reason was for compatibility, to make perl5's
killer app (the code on CPAN) immediately available to perl6, and hence
remove one perl5 to perl6 transition hurdle.

> Is there any reason it can't be moved further down the priority list?
> Seems more like a nice-to-have than being truely essential to ponie.
> (And may well end up being a can of worms.)

The principle reason I wanted to see if it can be made to work is
because having perl5 PMCs properly GCed means that there is no hassle in
passing them to non-perl5 routines, and non-perl5 routines storing them in
their parrot native GCed aggregates and it all just working.

I'm not convinced (admittedly after only 2 minutes' thought) that
refcounting PMCs, either via our own refcount, or letting parrot track
how many times we registered them, is going to work smoothly when we
pass them outside ponie. Whereas I think that having the refcount/GC
boundary at the RV/AV/HV/stack API presented to XS code will work.
(as there there are clear definitions of who owns references, unlike
on the perl stack as used internally between perl functions)

Please correct me if I'm wrong. I know I've not thought of everything here.

Nicholas Clark