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 <[email protected]> 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 can't. > 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
