ponie roadmap

Our current draft for how the ponie roadmap looks roughly like this:

Hide all SVs behind PMCs (done)

Move (at least) the refcount and SV flags into the PMC
  It might be possible to internalise all the PMC register/deregister PMCs
  inside the general SV routines, based on sv_free(), instead of the current
  arrangement.

Arrange the perl5 PMCs into a proper class hierarchy which reflects the perl5
hierarchy

[not sure:
 split out stashes into their own type
 I thought clone the existing macros to make pads and stacks and stashes
 continue to use the existing AV system, but Arthur notes that AVf_REIFY
 means that stacks can turn into real arrays, so this isn't going to work.]

Make RV a point direct to the PMC. Stop it being a ref-counted thing, and
instead rely on parrot's GC to keep things alive.
[I'm not sure how this interacts with SVs that are references but with magic,
ie use more than just the SvRV() field of the current SV body]

[Sort of decoupled at this point]
Convert the other SV bodies to store their data inside the PMC

Stop ref-counting things internally, and instead use proper Parrot GC.
[Need to work out where the line lies with extensions - ie how an extension
 declares whether it understands GC and will register any "SV"s it sticks
 into C heap structures, or whether it really is ref-counting,
 and particularly what happens with extensions which are GC-naïve which call
 back into ponie]

Move intelligence into PMCs. eg all the logic about integer types in pp_add
and the other maths ops.

Magic: [Here be dragons]
  Tie implementation converted to PMC vtables
  Overloading to PMCs
  Not sure how much other magic can be (easily) emulated.
  Binary compatibility on magic with perl5 may not be possible.

[Sort of decoupled - is this actually necessary?]
Make the peephole optimiser purely an optimiser - ie split the optimising
functions from the optree fixup functions.


At this point PMCs are smart, rather than merely data containers, and we're
basically using slim perl ops on the perl oploop.

Not sure how to do the oploop conversion

? Slim down perl ops so that they each become wrappers around parrot ops
  (or at least a wrapper round the same code that the new parrot op will use)
  And when all are converted it's big bang.

? make a perl5 op that is "enter parrot runloop" and a corresponding parrot
  op that is enter perl runloop, and jump between them as needed.
  So initially nearly every op will be perl5, but gradually they will move
  over until they are all perl.


Also, not sure how to generate parrot bytecode

? Via a B:: module hooked to the existing tokeniser

? hack the tokeniser to generate it directly


Comments?

Nicholas Clark