One of the most important changes in Perl 6 over earlier versions is that it has started out as a written specification, which may end up with several different implementations. In previous versions of Perl, alternative versions had to implement all the quirks of the official Perl interpreter, as the definition of the Perl language was “whatever the Perl interpreter will interpret”, which was (of course) a moving target, as each released version introduced new features and changed existing behaviour (though usually only on the peripheries of the language). The lack of a stable written specification killed off many useful projects, such as the Perl compiler (perlcc).
The written specification is what allows me to write this article right now, as the current implementations of Perl 6 are only partial — indeed, the specification is not yet complete, but I can comment on those parts that have been written. There are way too many changes to touch on them all, but I’ll try to write about some of the most…
" item,,http://tobyinkster.co.ukhttp://tobyinkster.co.uk/blog/2008/02/05/perl6/comments#comment1,Comment 001,"It sounds like this would break existing perl code!
One of the things that I like about perl is that there is over a decade’s worth of useful code out there that still works.
The huge archive that makes cpan such a useful resource didn’t happen overnight!
Regarding Parrot:
I know “virtual machines” are trendy, but I think the last thing I need is to see perl go the way of .net, java, etc and end up needing to load a huge, slow-to-start, memory-hungry VM just to do anything!
Perl 5 is nice and small, and runs on just about anything.
- keep it small - keep it simple -
" item,,http://tobyinkster.co.ukhttp://tobyinkster.co.uk/blog/2008/02/05/perl6/comments#comment2,Comment 002,"Syntax differences aside, Perl 6 code will be a proper superset of Perl 5. It will probably be possible to port Perl 5 to Perl 6 code with not much more than a few regexps. Whatsmore, it is likely that the Perl 6 interpreter will also support Perl 5 code unmodified, as it wouldn’t be a lot of extra effort to do so, and would provide huge benefits (e.g. the ability to use CPAN modules).
Regarding virtual machines: theoretically, bytecode should be faster to execute than an interpreted script. An interpreter needs to tokenise, parse and optimise a file before it gets executed, while a virtual machine doesn’t need to do any of that.
"