Re[2]: Patches that will come...

On Sat, 28 Aug 2004 15:35:42 +0100 Nicholas Clark <[email protected]> wrote:

> Sorry about the delay in responding. My time and energy is getting sucked up
> by the insides of work code, leaving little for anything perl related.
> (eg observe the progress on 5.8.6). The ponie hours bank is building up a
> good balance, but I'm not sure when I'll be able to withdraw it. :-(

  No problem. I did not have any time to fun work
(Parrot/Ponie/wxWidgets/wxPerl...) this week anyway :-/
 
> The roadmap *currently* looks like this draft:
> 
> ------------------------------------------------------------------------------
> 1: Data (about 3 months?)
> 
>  Dynamic PMCs

  I think this is done (modulo minor adjustments).

>  Data structure rearranging into something sane for PMCs (from perl5 layout)
>  Full PMC hierarchy

  I assume the PMC hierarchy resembles/is equal to the one described in the
"illustrated guts" by Gisle Aas?

The snapshot 3 announcement talked about

> * Make ponie's PMCs properly inherit in the perl5 class hierarchy
> * Move all the data access to PMC methods.
>
> which will allow all the perl data structures currently dangling off the PMCs
> to be eliminated.

  I do not understand: Perl5 PMCs will always need some data structures dangling
off the PMCs. Was that sentence talking about eliminating the head/tail split?
And anyway: what is the plan for the head/tail split? Currently we have

RV:    PMC -> referenced value (OK)
IV/NV: PMC -> head[IV/NV,flags,refcount,any(unused)]
other: PMC -> head[flags,refcount,IV/NV(unused),any]
              -> tail[more or less with the Perl5 layout]

where the head is the same for all SV types. The transition
I have in mind (and it might not work and might not be something needed)
is: eliminate the head, move the IV, NV, flags and refcount (until it is needed)
into the tail and have the tail hang off the PMC_data member.

>  Refcounting => GC

  I see various alternatives:

1a) leave things as it is now

1b) make Ponie GC-cooperative:
keep the current refcounting emulation, adding mark() methods
to compound data structures, to allow for native Parrot PMCs being stored
inside Ponie (for cross-language calls). This should allow most XS to work
unchanged.

2) switch to GC:
kill the refcount field, making SvREFCNT* no-ops and adding mark() methods
to compound data structures. This will break a lot of existing XS, and has
a deep impact on Perl code relying on the current refcount implementation.

The option 2 requires further discussion about the guarantees for object
finalization (Perl5 is "as soon as the SV is not referenced", Perl6 
(IIRC) is "at the end of a scope", other languages have "eventually" and "maybe").
And about its feasibility, of course.

>  Convert arrays,pads,hashes,stashes to something native PMC

  Hmm. If I read this as "Convert arrays,pads,hashes,stashes to be
properly-implemented PMCs, having Ponie guts accessing them (mostly) through
PMC vtable" I can see ways of doing it. But if for "native PMC" you
mean the PerlHash/Hash from Parrot, I don't think there is any way of doing
it keeping the current av_/hv_* API for XS.

> 2: Magic
> 
>  tie
>  overload
>  other (%ENV, %SIG etc)

  Clear enough for tie and other, I need to think about overloading and
its Perl5 sematics.

> 3: Simplify ops
>    (Perl5 ops have a lot of logic in them. Parrot puts the logic into vtables
>     So need to migrate the perl5 logic into the perl5 PMCs)
> 
> together 3 months? Might be better to do 3 before 2, except that I think we
> need overloading done the parrot way before we can usefully simplify ops.

  I agree that you probably need to do 2 before 3, or you can do them together
incrementally. For example you can do tie and magic vars (with related ops)
first and then (or in parallel) do overloading and related ops.

<snip "far" future>

> ------------------------------------------------------------------------------
> 
> 
> The problem I find is that quite often I start work on the first logical task
> and then discover something important that I've missed, or didn't know needed
> doing. And because of this it's very difficult to parallelise tasks on the
> main line.

  Yes. This is what I discovered (in small scale). 
 
> The patch you say you have to allow building of dynamic PMCs in place would
> be very useful (as it's at the top of the list).

  See the other post.

> The calling from parrot to perl and back doesn't sit on that roadmap, but I
> think is actually useful (and won't rapidly get thrown away, which is always
> my fear for the fate of other people's work) because it will make ponie far
> more useful for people to start experimenting with parrot, parrot assembler
> and other things in parrot. And ponie being useful will lead to interest,
> which is never bad :-)

  I did it as a preparation for the optree -> bytecode translator: once you have
Parrot::Ponie + calling subroutines/methods, you can start toying with bytecode
generation on small scale, writing the translator in Perl with B.pm (as you wrote
above).

> I'm not sure how the array stuff fits in - my problem is that it might
> rapidly become irrelevant when the refcounting/GC mess is resolved.

  I think it is relevant to solving the refcounting/GC mess, depending
on if you choose the alternative 1 or (some variant of) 2 above.

> I don't think that parrot has a make install target yet does it? ponie doesn't
> have one, because parrot didn't.

  No, but this isn't on my short-term TODO list.

> What ponie also can't currently do is build on Win32. I don't have access
> to any Win32 machine with a compiler, and even if I did I don't have the
> knowledge of how Windows development works to get things done correctly,
> so unfortunately this is stalled. Steve Hay had a valiant attempt at making
> it work, but it got the better of him. [mmm, I'm really good at selling this,
> aren't I? :-)]

  Not on my short term TODO, either. I am still hoping somebody braver will
pick it up before my short term TODO becomes empty... 

Currently my short term TODO list is:

* rework PMCs in the correct inheritance hierarchy
* try to fix whatever needs fixing in the refcount/GC mess
* implement Parrot_call_method (Parrot work, done, need to send patch)
* finalize the patch for Perl -> Parrot calls,
  adding methods as well
* implement tied/magical arrays/hashes

the bad news is that I have no idea when I will have the time for even the
first item :-( I will send a warning when/if I start working on something,
just to avoid effort duplication.

Regards
Mattia