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 or NQP 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.
Will MOAR be relicensed to the TPF?
I don’t know that relicensing MoarVM to TPF has been discussed, but at this point I think it’s doubtful it’ll be relicensed or that there’s a compelling reason to do so.
MoarVM is already an open-source project (Artistic License 2.0), so what would “relicensing it to the TPF” mean? Is it about trademarks and such?
It’s not clear to me precisely what’s being asked, but I assume it’s something like, “will we make it so TPF holds the compilation copyright on MoarVM”. So far as I’m aware, it’s not come up before and so not been discussed; this is the first time I’ve seen anybody asking the question.
Given the context of this is about Parrot, it’s also worth noting that Parrot’s compilation copyright is also not held by The Perl Foundation as far as I’m aware, but The Parrot Foundation. Rakudo itself has the compilation copyright held by The Perl Foundation, while is why folks have to sign a CLA to get a commit bit. By contrast, the MoarVM licensing setup was modeled off the NQP one.
i’m confused about the underlying VM platform choice. will the JVM be primary? MoarVM? neither (equal footing)?
I don’t see that we need to (or should) declare a primary backend VM.
For the purposes of the upcoming Perl 6 release candidate we will probably emphasize Rakudo on MoarVM, but that should not be taken as a declaration that it’s the “primary” platform going forward after that.
Is there any chance that nqp will eventually disappear?
Nqp is simpler than Perl 6 so easier to optimise but it means that anyone who want to contribute to the internal of rakudo or make slangs must learn nqp and all the tricks to cross the boundaries between nqp values and rakudo values. Also nqp is undocumented and unforgiving.
I don’t have any plans to eliminate NQP anytime soon.
Personally, I feel that NQP is the toolchain that Parrot needed to have to be successful. It ought to be relatively easy to use NQP implement other languages (e.g., Python, Tcl, Ruby, etc.) — after all, we implement Perl 6 with NQP — and then NQP provides a decent level of interoperability between the different languages..
Eliminating NQP won’t make Rakudo internals any easier; in some ways it makes them harder (because it’s a very useful abstraction layer). Either that, or we just end up duplicating the same abstractions in Rakudo that NQP provides, in which case we might as well keep NQP as a separate component.
NQP can become documented and forgiving… that just hasn’t been a focus for us yet. As NQP expands out from its hyper-focus on Rakudo Perl 6, I expect its documentation and usability to improve.
Pingback: Announce: Rakudo Star Release 2015.02 | rakudo.org
Reini is upset. He has noted that there was “no single Parrot ticket” to get NFG in to the Parrot VM. He has suggested it was Rakudo devs’ responsibility to file such a ticket. Please consider commenting. Thanks.
And thanks for applying your brilliant whirlpool herding instincts to P6. 🙂
As for me, I didn’t realize that NFG was going to be a Perl 6 release requirement. So, it didn’t get a Parrot ticket because we really wanted to prioritize progress on other items (e.g., performance).
Beyond that, adding NFG support is something that Parrot had identified as an important and necessary feature at least as far back as 2010 (try a Google search for “parrot nfg”). So, given that Parrot had already identified this as being an important feature, I’m not sure that Rakudo developers are solely responsible for making sure there’s a ticket for it.
Hey, sorry to get off topic. I’m trying to contact you. Can you email me please? Thanks!