Respectively: Not at all, and not without major contortions. The languages have diverged a lot; even basic tasks like defining a function are not the same.
You are mistaken. See my nearby comment about Inline::Perl5.
> not without major contortions [can one convert].
One doesn't need to convert (due to Inline::Perl5).
That said there can be valid reasons (eg having fun and learning Perl 6) to want to convert existing Perl 5 code to a Perl 6 equivalent anyway. While some partial P5-to-P6 conversion tools already exist[1] (and I'd be surprised if more don't arrive in the future[2]), conversion of a well written Perl 5 module in to a well written Perl 6 module is mostly a manual exercise.[3]
> even basic tasks like defining a function are not the same.
sub foo ($foo, @bar) {
my $qux;
# do something
return $qux
}
Could you provide some code to illustrate what you mean?
---
[1] http://www.perlito.org/perlito/perlito5to6.html Incomplete but better than nothing.
[2] https://github.com/rakudo-p5/v5/ is a project to create a Perl 5 compiler written in Perl 6. It parses Perl 5 code and spits out Perl 6 ASTs. It's obviously not a huge jump for it to spit out straight Perl 6 code. One day...
[3] http://jnthn.github.io/css-tiny-presentation/presentation/#/
sub foo {
my ($foo, @bar) = @_;
...
}
As a practical programmer, I have enjoyed signatures and run-time type checking for years, provided by libraries. Even now, these libraries are more featureful than core signatures.
So, to recap:
> Can one even use CPAN with Perl6?
Yes.
A Perl 5 coder might write:
use Data::Dumper;
print Data::Dumper->Dump([1]);
use Data::Dumper:from<Perl5>;
print Data::Dumper.Dump([1]);
(Another important `from` option in Perl 6 that's currently being brought up to production grade is `:from<Java>`.)
The `.` rather than a `->` in the print statement line is another giveaway that this is Perl 6 code. And the `[1]`; is that a Perl 5 or a Perl 6 array literal? It doesn't matter. This line is a taste of how slick Perl 6 interop magic is. You barely notice it, but the language is automatically marshaling data and objects back and forth between languages as necessary.
Of course, the above is a trivial example. But that's not because complex examples don't work; within a few weeks of starting Inline::Perl5 its author Stefan Seifert was demoing a Catalyst app written in Perl 6. That needed fancy stuff beyond mere passing objects back and forth; in this case Perl 6 code had to subclass a class from another language, in this case Perl 5, and have Perl 5 accept objects made with the subclass as if they were Perl 5 objects made from a Perl 5 subclass.
Inline::Perl5 hasn't yet been smoke tested with all 130,000 CPAN modules, and it will no doubt fail with a few, and a similar story applies for the even more immature support for calling Java libs, but this tech ought to be a game changer, at least within the Perl community.
> Is it even possible to convert existing Perl5 CPAN packages?
There's no need. (See previous point.)
But if you really want to, then yes it is possible, and seems to be enjoyable. Reports I've read of P5-to-P6 conversion stories tend to express satisfaction that basic syntax is generally the same, the changes that are necessary make sense, and the final code is a lot shorter, often half the length, and is very readable.
It's not all roses with Perl 6. There's plenty to bitch about. (#1 is still speed.) But use of CPAN modules, and writing Perl 6 code alongside Perl 5 code, are quickly shifting over to the strengths column for Perl 6, not the weakness one.
While not quite the same as what was asked, it's clear that 'not at all' is not an informed answer
But Inline::Perl5 is a completely different animal. It handles modules using XS or whatever fine. See my nearby comments for further details.