Except that if you follow perl6-language you can watch the thing warp all over the place. Larrys apocalypses provide an outline but AFAIK reality doesn't actually conform to those.

__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;
[download]

Possibly the P6P digest is possibly a better way of keeping up to date, requires more work to plow through than the apocalypses though.

Perl6-language is a place to discuss potential new language features and changed old language features. Don't make the mistake of assuming that it's the final word on perl 6....

Don't know if this is the answer you are looking for, but it is hopefully just as helpful as "go read the apocolypses". {g}

For me the biggest single change going into Perl6 is the fact that the front-end and back-end are being separated. This is to say that today Perl5 consists of front-end interpreter that turns your code into byte-code. It also has a back-end virtual machine that executes your byte-code. The various B modules let you play with this split personality of Perl5 today, for example enabling you produce a "byte-code executable" (somewhat akin to a Java jar file or a Python .pyc file), and in a separate step call the Perl VM just to execute the byte-code. (This can have a marginal speed advantage, but only in how quickly your application starts.)

Perl6 is going to formalize this process, meaning that while a single step source-code->byte-code->(IMCC->)VM will still be supported (at least I really hope so) explicitely calling the steps on your own will be easier to do. The back-end of this process is called Parrot, which looks like it is going to be a very robust and useful virtual machine. Already there are a number of languages (besides Perl6) that target it (with widely varying success - it is very much a moving target of its own). The front end will be a byte-code compiler for Perl6, but unlike Perl5 it will be possible to write the front-end in Perl itself, which makes all kinds of interesting and scary things possible (that is to say the statement that "only perl can parse Perl" will no longer be true).

This may not be a huge advantage to your run of the mill Perl hacker, but to your low-level language freaks this is super-cool. Basically, the goal is to be able to make it easy to make any language run on Parrot by writing a compiler for it that generates Parrot assembly (PASM). The really neat-o thing is that this makes Parrot a lot like a Mono or .NET VM - you'd be able to have components written in Perl6, Python, and who knows what else, and have them interact as one big, happy program. (Of course, supporting such a system sounds like madness to me, but that's probably why I'm not the management type.)

If you noticed I mentioned a source-code->byte-code->(IMCC->)VM chain before. I am merely a watcher of Perl6 development, so some of the ambiguity of my statements are related to the fact that I'm simplifying my already poor understanding of the work being done. Suffice it to say that between source-code and VM the code goes through a few steps, all of which are designed to be rather moduler. For a Perl6 example I believe the chain would be the source-code would be converted to byte-code by a compiler written in Perl. The byte-code would be converted to PASM by the intermediate mode compiler (IMCC) which could then be executed by the VM itself. In theory this means that IMCC could target other things besides just Parrot. Do you want your Perl code running on the Python VM, or Mono or the JavaVM? Sounds fun to me.

From a purely Perl programmer's perspective what does this mean to you? Hard to say - as has been mentioned in this thread, the actually language spec is a moving target. I like some of the stuff I see on the language list but a lot of it scares me. Honestly, if your living is Perl you probably want to pay close attention to some of the stuff coming out of the Perl6 mailing lists. The steps they make to day are going to forever alter the viability of the Perl programming language we all know and love. I have confidence that what comes out of the process will be really cool. At the same time I am brushing up on my Python. The changes that are going into the language have the possibility of irrevocably fragmenting the Perl community. We might see that Perl5 splits from Perl6 and continues development on its own. If you really dig Perl I think your best chance is to convince everyone that Perl6 will be a great thing whether or not you believe it, because it is going to happen.

The beatings will continue until everyone loves Perl6. {g} Hope my long-winded and technically inaccurate discussion helps.

{NULE}
--
http://www.nule.org

Actually... perl5 creates an opcode tree directly from the perl source. You can peek at it by using such nifty tools as B::Concise. Bytecode is a serialization of an opcode tree but is not normally invoked by perl. The only time you deal with bytecode is when you want to save a compiled opcode tree out to disk.

Opcode trees are just a bunch of C structs hanging around in memory and pointing to each other. perl executes by following the links between each node and running routines along the way. I've accumulated some references to the opcode tree around and can post them if you're interested.

__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;
[download]