Parrot is a foundering project on top of a wonderful vision.

Andrew Whitworth wknight8111 at
Tue Sep 6 13:40:06 UTC 2011

I'm very strongly in favor of this new idea and am looking forward to
getting started on some of the necessary work that needs to be done.
There are some things that need to be broken so they can be re-made
better. Just off the top of my head, things like PCC, Exceptions, MMD
and the object model are going to need some disruptive changes in the
coming months, and having the freedom to pursue the correct course of
action without having to wait months at a time for deprecation periods
to elapse is good. Relying on abstraction layers like NQP and Winxed
are going to be extremely important during this time.

On Mon, Sep 5, 2011 at 10:19 PM, Jimmy Zhuo <jimmy.zhuo at> wrote:
> I agree with cotto, I don't even think parrot needs a deprecation
> policy right now since parrot is not stable enough. And I don't think
> parrot should keep lua/partcl working on parrot any new release.

Lua has been extremely stable in the past. It works now and has worked
for a long time. It also tends to be very easy to maintain. I don't
think we need to drop Lua support for any reason, and having it around
is a good thing. We may want to start transitioning it away from being
written in so much PIR code, but that's something we can talk about in
the future. Having a working Lua brings us several benefits, including
a new dimension of testability, the ability to test language interop
(you need at least two HLLs to test interop, and we have working Lua
right now), etc.

If the new Partcl is written in NQP, and if we're going to try and
keep NQP stable, partcl should continue to be mostly stable. Mostly. I
don't know its current status but I do know that historically it has
been more fragile than Lua. If we have people who are interested in
working on it, we should continue to support that effort. If not, we

> and then what parrot's goal? In my opinion, I think it should be
> making rakudo better on parrot, keeping winxed working, and then
> making parrot better for other languages.

That's a great point. We do need to improve the Rakudo experience.
That needs to be a big focus of our efforts in the coming months.
It's been said before that Parrot development moves too slow for
Rakudo, and that is the very first thing that should change. Parrot
should be moving quickly enough for Rakudo to have necessary changes
added to Parrot core with minimal effort. Obviously we need to find
ways to take the things Rakudo needs and present them in a way that
can be usable by other languages. Our biggest user right now is
Rakudo, and they also happen to be one of the bigger drivers of
improvements at the Parrot level. We need to make it easier for their
changes and their needs to be added to the core Parrot repo.

--Andrew Whitworth

More information about the parrot-dev mailing list