Skip to content

Instantly share code, notes, and snippets.

@pmichaud
Created February 4, 2015 17:42
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pmichaud/7494d7630caf66951282 to your computer and use it in GitHub Desktop.
Save pmichaud/7494d7630caf66951282 to your computer and use it in GitHub Desktop.
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).
Beyond this, at present we don't have any developers on hand that seem
eager to tackle these problems for Parrot, nor do we seem to have a high
demand for Parrot support in our userbase. Most people seem to have
switched over to using MoarVM as the backend, for many reasons.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment