Howdy. Right now, the toolchain is written in a mix of Perl5, PIR, NQP and Winxed. I don't think I need to elaborate why this is not an ideal situation.
I propose moving build tools to Perl5 and developer tools to Perl6, where a build tool is a program that gets run when an end-user checks out the codebase and wants to install Rakudo, whereas a developer tool only needs to be run after changes to the codebase have been made. The most immediate concern would be ops2c. It is run during the build process to parse dynop definitions and according to policy the old P5 implementation should be resurrected. However, I don't see a problem with moving it to the dev tools category and porting the NQP-rx codebase to P6: Right now, the generated files for core ops are checked-in, and I believe this could be done for dynops as well. Rakudo devs should weigh in here as it would affect their development process as well (a P6 ops2c would need to be run after dynop changes instead of as a part of regular builds), but I believe the benefits would be worth this hopefully minor inconvenience (dynops change rarely, correct?). So why choose P6 instead of NQP as the implementation language for dev tools? Because NQP is not the user-facing product - P6 is. I'm not aware of any policy governing the stability of NQP, and the migration from NQP-rx to NQP would be a case in point. Thoughts? -- gerdr _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
