Suspending Rakudo support for Parrot (draft)

gistfile1.txt

Suspending Rakudo support for Parrot

This past weekend at FOSDEM 2015, Larry announced that there will likely 
be a Perl 6 release candidate in 2015, possibly around the September 
timeframe.  What we're aiming for is concurrent publication of a 
language specification that has been implemented and tested in at least 
one usable compilation environment -- i.e., Rakudo Perl 6.

So, for the rest of 2015, we can expect the Rakudo development team to 
be highly focused on doing only those things needed to prepare for the 
Perl 6 release later in the year.  And, from previous planning and 
discussion, we know that there are three major areas that need work prior 
to release: the Great List Refactor (GLR), Native Shaped Arrays (NSA), 
and Normalization Form Grapheme (NFG).

...which brings us to Parrot.  Each of the above items is made 
significantly more complicated by Rakudo's ongoing support for Parrot, 
either because Parrot lacks key features needed for implementation 
(NSA, NFG) or because a lot of special-case code is being used to 
maintain adequate performance (lists and GLR).

At present most of the current userbase has switched over to MoarVM 
as the backend, for a multitude of reasons.  And more importantly, 
there currently aren't any Rakudo developers on hand that are eager 
to tackle these problems for Parrot.

In order to better focus our limited resources on the tasks needed 
for a Perl 6 language release later in the year, we're expecting to 
suspend Rakudo's support for the Parrot backend sometime shortly 
after the 2015.02 release.

Unfortunately the changes that need to be made, especially for the 
GLR, make it impractical to simply leave existing Parrot support in 
place and have it continue to work at a "degraded" level.  Many of 
the underlying assumptions will be changing.  It will instead be more 
effective to (re)build the new systems without Parrot support and 
then re-establish Parrot as if it is a new backend VM for Rakudo, 
following the techniques that were used to create JVM, MoarVM, and 
other backends for Rakudo.

NQP will continue to support Parrot as before; none of the Rakudo 
refactorings require any changes to NQP.

If there are people that want to work on refactoring Rakudo's 
support for Parrot so that it's more consistent with the other VMs, 
we can certainly point them in the right direction.  For the GLR this 
will mainly consists of migrating parrot-specific code from Rakudo 
into NQP's APIs.  For the NSA and NFG work, it will involve developing 
a lot of new code and feature capabilities that Parrot doesn't possess. 

I think it would be rather short sighted to kill parrot, since it provides more architectures, better threads support (scaling linearily over the HW cores, not blocking on every single shared data access as in moar), better code quality and project management support than moar.

NSA: nqp-only. parrot has native arrays forever, not just PMCs, nqp just needs to use them.
In sized and non-sized (i.e. run-time sizable) variants.
NFG: parrot-only. This could be easily ported over from moar to parrot. Is it a high priority? I thought performance was highest priority, that's why I worked on that. With occasional GC fixes.
GLR: nqp-only? Where are the changes and problems described? I thought it's a NQP-rakudo problem only.

But on the other hand, if you kill parrot, I can go on improving perl5 finally. Which would be a more worthwhile goal in the short term.
Long term, having blocking threads will kill perl6, as it killed php, python, perl5 and soon ruby. Your decision.

NSA: The native arrays that Parrot provides aren't really what Perl 6 needs; we need more than just "num", "str", and "int" (as Parrot defines them).

NFG: We've identified NFG support as being important for over seven years. It's not been our highest priority -- speed has definitely been the highest priority -- but we're now at a point where we can begin looking at NFG implementation.

GLR: Currently Rakudo on Parrot manages adequate performance with lists only by having a lot of special-cased embedded PIR code that the other backends do not require. Re-implementing the PIR side of things in the GLR will add a lot of development overhead and continue to bloat Rakudo's codebase, so I'm not going to pursue that at this time. It's fair to claim that this is actually something that belongs in NQP... but the overall point remains -- we don't have any developers that are eager to tackle this problem for Parrot.