On Fri, Feb 15, 2013 at 12:45:17PM +0100, Gerhard R. wrote: > 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. > [...]
First, a general note: There seems to be a general assumption in this message that NQP's only reason for existence is to build Rakudo, and that Rakudo is its only user. That isn't the case. We do intend that NQP will be a platform for building other languages, compilers, and libraries. TLDR: If ops2c is to be Perl 6 code, please make sure it can be run by NQP. Don't rush to make Rakudo into a dependency for Parrot and NQP developers, especially while we have install-versus-local copy issues remaining. > 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?). I'm very much against this "dynops change rarely" assumption, especially if Parrot is charting some new directions. Parrot needs to make some big internals changes, and I suspect those changes will involve some significant refactoring of ops, at all levels. > So why choose P6 instead of NQP as the implementation language for dev > tools? Because NQP is not the user-facing product - P6 is. For compiler writers and people who would be working at the dynop level, NQP is the "user-facing product", not Rakudo. > 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. NQP is fairly stable at the user-facing level, although that stability may change as we continue to develop other vm targets. But we do intend for NQP to be remain fairly consistent over time. The migration from nqp-rx to NQP is truly not a "case in point" about NQP's stability, because NQP was always expected to be a significant break from nqp-rx. Personally, if I'm making changes to operators in Parrot, NQP, or language XYZ, I don't really want to have a fully installed copy of Rakudo + libraries lying around to do it. I also don't want to worry about failures caused by mixups between the development versions I'm working on and the installed ones I'm having to use (these still exist in Parrot, NQP, and Rakudo). Bottom line: If ops2c is to remain Perl 6 code, please target NQP and not Rakudo. Pm _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
