RFC: Move build tools to Perl5, developer tools to Perl6

[Patrick R. Michaud]

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