On Wed, 2002-09-04 at 15:48, Steve Fink wrote: > I'm actually somewhat surprised at how little Parrot is tied to Perl.
I've no clue whether I agree or not. OT1H, given its origins from the bosom of Perl, Parrot is surprisingly independent. OTOH, compare where Parrot is to where it *might* have been had it started as a completely independent project. When I went back to resolve once-and-for-all the Perl or Parrot Design Document debate earlier, I felt that to truly make Parrot independent, not only would I have to change the name throughout PDD 0, but I would have to revisit and revalidate - from a language-neutral position - all of the original decisions. Some points would need to be removed. Others added. Should POD remain the documentation standard? It made sense at the time, because this was just Perl. Would a language-neutral group reach the same conclusion? Or would we be supplying our documentation in *ML/text/*roff? Would Perl be the configuration/utility language of choice, vice Bourne, C, autoconf, ...? Even something as trivial as version numbers may or may not apply. Parrot was just one small part of Perl that we were reinventing. Now it's one big part of itself. It will be hard to "untaint" the early Parrot work without seeming to continue to be Perl-specific. In fact, *because* of how Parrot (the project) was developed, we'd probably need to *overcompensate* the shift away, just to make the field seem level to other languages. Of all the areas of Perl overlap, however, the one that is *most* critical to Parrot's independence is both the one most people have labeled as unimportant, and will be the one that will be most difficult to maintain and deal with on a daily basis, and that's the mailing list. It's great that we've got a bunch of toy languages that we provide, but we're not providing Perl 6 as a toy. Its development *must* move out of the parrot tree, and that means that we've got to draw a rigid line between the two. Trying to have Perl 6 internals (in terms of Parrot) and Parrot internals discussed on the same list will lead to a blurring of that line, with all the standard ramifications of making assumptions in code, etc, etc. (Not to mention driving the developers crazy who have to weed out mail on the project they're not interested in.) So since Parrot's history is on perl6-internals, Perl 6 internals work should spin off onto parrot-externals. Problem solved. They're separated. :-) Two other human X factors to consider: First, with Perl 6 being developed onto a moving target, there are undoubtedly going to be Perl 6 bugs/features/patches/additions that are going to cross the line into the Parrot cage. It happens in concurrent development. It's going to take effort to keep the two apart. Second, while Parrot remains mainly supported by Perl 6 developers, it's going to be a burden on the bulk of that community to force themselves into those two different mindsets. I'm simply amazed that Nicholas Clark is able to play in both the Perl 5 and Parrot arenas, but they have very little overlap in the areas being addressed. It makes little sense to spawn a new list if 90% of the messages are cc:d to the other one. So that's what I feel is the difficult decision to make: the situation as it currently stands is *easiest* on the known developer base, but creates a barrier of entry for non-Perl implementers. However, we can make things easier for others to get more of a community buy-in, at the expense of effort by the Perl folks, but there's no guarantee that those people will come. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
