NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
I pour the blue liquid on the red liquid. If it doesn't blow up on my
face, I proceed to turn up the flame under the blue liquid, and so on.
I have very little idea of what I am really doing, I just like the
pretty colors :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Back-compatibility is compulsory (Score:1)
CPAN is so central to the success of Perl 5 that even Perl 6 won't break back-compatibility.
So let's forget about that right now.
Large changes are also very tricky.
There's some small things we can do, in fact we've been experimenting with them in the JSAN implementation.
Things like:
- Multiple Indexes
- Mirror Validation and HTTP-centric rather than FTP-centric transport
There's also plans from the Win32 side of things like a GUI failure-reporting CPAN client.
Re:Back-compatibility is compulsory (Score:1)
Well, the incompatible syntax of Perl 6 will be doing that anyway. The fact is, there will eventually be code on the CPAN that perl 5 cannot run.* If we do it very carefully, we can use this opportunity to do some really nice things for those Perl 6 modules.
Wouldn't it be nice to have an infrastructure where we could have all those without brokenishness? Part of it is submitting patches to those projects. Part of it may be thinking carefully about how everything is structured.
* Even with v6.pm, (which is another awesome project), I don't see how you could wrap all the P6 code so that it would look like P5 + v6.pm to perl 5. I could be wrong.
Reply to This
Parent