# New Ticket Created by Allison Randal # Please include the string: [perl #41888] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41888 >
When I updated the Parrot FAQ, I removed some Perl 6 related text. This ticket is so Patrick can review it and decide if he wants any of the text for languages/perl6/. Allison
=head2 Is Parrot the same as Perl 6? Parrot is an implementation that is expected to be used to execute Perl 6 programs. The Perl 6 language definition is currently being crafted by Larry Wall. While the true nature of Perl 6 is still unknown, it will be substantially similar to Perl as we know it today, and will need a runtime system. For more information on the nascent Perl 6 language definition, check out Larry's L<apocalypses|"LINKS">. =head2 Pugs is going great shakes - why not just toss Parrot and run Perl 6 on Pugs? Perl 5 is highly portable, and builds on around 50 different systems, many far removed from Unix or MS Windows. We'd like Perl 6 to be able run everywhere that Perl 5 runs, so we need to keep Parrot as portable as possible. The Glasgow Haskell Compiler is a pain to build on minor systems, and downright impossible on small systems. So by going with Pugs and GHC we'd be sacrificing portability. As well, other languages apart from Perl 6 are being targeted to Parrot. Significant parts of Python, Tcl, and Basic have already been implemented, and others are on the way. Running multiple languages on the same Parrot engine allows them to be cross-language compatible-- in other words, one targeted language could directly invoke the methods of another at the bytecode level. Finally there is a reason the Parrot design keeps talking about running bytecode direct from disk rather than relying on doing compiling (from Perl or with a JIT) in memory. It's all very well doing such operations when running one program, but think what happens on a multi-user system when 300 people fire up "parrot order.pbc" - 300 parrot processes all fighting for resources. To quote Dan, non-jit vss/rss is 29784 17312, JIT vss/rss is 122032 108916. A not insignificant difference :) With read only bytecode shared between processes, much of that "non-jit" resident memory is going to be shared. So much less swapping. And don't think that this won't matter to you because you don't have 300 users all running the same program - consider what happens if each Perl 6 module is compiled to bytecode. With read only bytecode 300 different Perl scripts all share the same memory for Carp.pbc, warnings.pbc, etc. Without, and they're all swapping like crazy... =head2 OK, so Parrot is fast... Pugs can back-end to Parrot, right? There was an early attempt for Pugs to target Parrot, but at the moment it is not actively maintained; instead, look into the F<languages/perl6/> directory in the Parrot source tree for an implementation that does not depend on either GHC or Perl 5's runtime. Still, the ultimate goal is for the Perl 6 compiler to be self-hosting (that is, written in itself) in order to improve introspection, debugger capabilities and compile-time semantic modulation. See L<http://dev.perl.org/perl6/doc/design/syn/S01.html#Project_Plan> for further discussions on Perl 6's project plan. =head1 PARROT AND PERL =head2 Why re-implement Perl? Good question. At The Perl Conference 4.0, in the summer of 2000, Larry Wall L<announced|"LINKS"> that it was time to recreate Perl from the ground up. This included the Perl language, the implementation of that language, the community of open source developers who volunteer to implement and maintain the language, and the larger community of programmers who use Perl. A variety of reasons were given for embarking on this project: =over 4 =item * Perl 5 is a stable, reliable, robust platform for developing software; it's not going away for a long time, even after Perl 6 is released. (Proof: Perl 4 is still out there, no matter how much we all want it to go away.) =item * We have the ability to translate Perl 5 into Perl 6 if necessary. This preserves backward compatibility with a large body of existing Perl code, which is I<very> important. =item * The language can stand some revision: formats don't really belong in the core language, and typeglobs have outlived their usefulness. By revising the language now, we can make Perl better. =item * Some warts really should be removed: C<system> should return I<true> instead of I<false> on success, and C<localtime> should return the year, not the year - 1900. =item * It would be nice to write the Perl to Bytecode compiler in Perl, instead of C. That would make it much easier for Perl hackers to hack on Perl. =back =head2 You want to write the Perl compiler in Perl? Sure. Why not? C, Java, Lisp, Scheme, and practically every other language is self-hoisting. Why not? =head2 Isn't there a bootstrapping problem? No, not really. Don't forget that we can use Perl 5 to run Perl 5 programs, such as a Perl 5 to Parrot compiler. =head2 How will Parrot handle both Perl 5 and Perl 6? We don't know yet, since it depends on the Perl 6 language definition. But we I<could> use the more appropriate of two Perl compilers, depending of whether we're compiling Perl 5 or Perl 6. Larry has mumbled something about a C<package> statement declaring that the file is Perl 5, but we're still not quite sure on how that fits in. =head2 Is this how Parrot will run Python, Ruby, and Tcl code? Probably. =head2 Latin and Klingon too? No, Parrot won't be twisted enough for Damian. Perhaps when Parrot is ported to a pair of supercooled calcium ions, though... =head2 Huh? You had to L<be there|"LINKS">. =head1 LINKS apocalypses: L<http://dev.perl.org/perl6/apocalypse/> exegeses: L<http://dev.perl.org/perl6/exegesis/> synopses: L<http://dev.perl.org/perl6/synopsis/> be there: L<http://www.csse.monash.edu.au/~damian/papers/#Superpositions> L<http://www.perl.com/pub/a/2000/10/23/soto2000.html>
