On Sat, Jan 29, 2011 at 18:51, Bruce Gray <[email protected]> wrote: > Note: this ended up looking like a call for a Policy, when really it is > just a request for guidance and timely discussion. Also, much of it was > written amidst the PDS heated discussion of NQP's suitability to remain in > the Parrot repo. Later discussion in #parrot looks to have arrived at an > amicable consensus, but I am not *sure* that the removal from the repo is > off the table. Even if so, the questions are worth asking. (and I already > typed them). > thank you for organizing these questions, bruce. let me address this one now:
> Not-Quite-NQP? > Something similar to NQP could be created, to forever be oriented to > Parrot's own needs. Particle mentioned forking the current NQP. > my understanding of patrick's and jonathan's plans for nqp are that the version in the works is an almost complete rewrite of the current version, and that the new version will reside in a new repository. nqp-rx is the current version (i'm using this term loosely, forgive me) of nqp, and is being replaced with another version which drops the "rx" suffix, so it is once again called nqp. this rewrite enables (among other reasons) multiple back-ends for nqp (e.g. clr, jvm, parrot, etc). rakudo will no longer use nqp-rx and will instead rely on the new nqp. the concern with parrot supporting the new nqp is that any tools we write using nqp can be easily ported to any other vm. however altruistic, portability from parrot to other backends is not currently one of parrot's goals. in fact, chromatic, myself, and others believe it may be harmful to parrot's future to support portability of nqp-based parrot tools to other backends. parrot is simply not in a position to compete with more mature virtual machines yet, and the risk that the new nqp's portability poses is significant. none of this prevents parrot from continuing to use the existing nqp-rx. it is likely that no change to parrot's nqp-based toolchain is necessary, however small changes may be desired (or required) to make clear the distinction between the new nqp and nqp-rx. parrot may not even need to fork nqp-rx, if the nqp team agrees to give over ownership of nqp-rx to parrot, or agrees to give parrot folks liberal commit rights to nqp-rx. to my knowledge nobody has approached the nqp team with a proposal similar to those i mentioned above. in the unlikely event that the nqp team is not receptive, a fork of nqp-rx is simple, straightforward, and justified. i will not pretend to speak for the parrot development team and recommend we march forward with nqp-rx and ignore alternative solutions. clearly there are other ways to provide parrot core toolsmiths with a parrot-focused high-level language, as bruce has begun to enumerate in his original post. i only wish to point out the specific risks associated with the new version of nqp. ~jerry _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
