To see what is currently happening visit http://www.perl6.org/
The syntax tree enters the compiler. The compiler spits out bytecode.
The bytecode enters the optimizer. The optimizer spits out more bytecode.
(But better!)
The bytecode enters the runtime, which then Does Something with the
bytecode. (Presumably run it, but possibly turn it to Java bytecode,
or
.NET bytecode, or an Alpha executable, or an encoded DNA sequence for
fruitflies or something)
Or, in glorious ASCII art form (data flows from top to bottom):
Source Code +------------+ | The Parser | +------------+ Syntax Tree +--------------+ | The Compiler | +--------------+ Byte Code +--------------------+ | Bytecode Optimizer | +--------------------+ Better Byte Code +---------+ | Runtime | +---------+ |
The runtime engine (which Dan has codenamed "Parrot") is a register-based virtual machine (compare to the perl5 virtual machine, which is stack-based). Combined with this and work on vtables (values have tables of operations attached to them), we hope the virtual machine will be faster and more powerful than that of perl5.
One of the major reasons to revisit Perl was to fix the mess that is XS (the way you extend Perl with C or C++ subroutines). Perl5 has no API for extension, separate from the functions used to implement Perl, and extending Perl requires hideous amounts of work. Dan and Larry are aiming to make C extensions as easy as they possibly can be (Brian Ingerson's excellent perl5 Inline modules give some directions for this). Anyone who has used XS looks forward to its demise.
Perl5 was designed in such a way that it would run wherever there was C. These days, though, it's becoming more and more common to not have C but instead to have some kind of virtual machine (JVM, .NET, etc.). So we'd like to have our own virtual machine that will run wherever there's C, but also to make it easy to port the bytecode to another virtual machine for places without C.
For more information, look for Dan Sugalski's Perl6 internals slides in the talks section.