v5

There is the v5 project implementing Perl 5 targetting nqp to be compiled inline with a Perl 6 program. https://github.com/rakudo-p5/v5 The project has mostly stalled since Inline::Perl5 became so effective. v5 had the issue of being unable to easily support binary XS type modules. Which means it could never support CPAN, unlike Inline::Perl5. It was meant for people to be able to copy their high mental cost algo code into a new Perl 6 project without fuss.

https://github.com/niner/Inline-Perl5/ https://github.com/rakudo-p5/v5/

Perl 6 started around when perl 5.8 was released. Then Perl 5 went stagnant while most of the core language developers were working on Perl 6. After a few years where there were competing implementations of perl 6, and still some wild ideas being tested, folks that still were using Perl 5 watched the rest of the languages develop, and the growing buglist against perl 5, and starting poaching ideas from Perl 6, ruby, python, and improving the Perl 5 runtime. Eventually, The Perl 5 camp committed to regular releases, and continued renewed development in the engine, and it is still pretty good. But the damage has been done @ this point -- a lot of the community has wandered off to other 'cool' languages and frameworks. The confusion will continue, especially since it's become clear Perl 6 is quite the departure from Perl 5, and there is a

> Not at all [can one use CPAN] 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 } This is the same in both languages. Could you provide some code to illustrate what you mean? --- [1] http://www.perlito.org

Respectively: https://github.com/rakudo-p5/v5 While not quite the same as what was asked, it's clear that 'not at all' is not an informed answer

Perl 6 claims saner defaults. For the strict pragma, it's off by default for one liners and on by default for everything else. A much bigger relevant change is Perl 6's support for hygienic lexically scoped "slangs". These can be used to relatively cleanly package composable dialects, DSLs, language tweaks etc. Slangs make it practical for a group to establish a default local policy (policies include anything from switching some language tweak on or off to switching to another language entirely) and for an individual programmer to extend or alter that policy in a cooperative manner. Slangs aren't yet nearly as easy as they supposed to be, but they're getting there. A couple examples are v5 (which switches to another lang entirely) and Tuxic (a tiny idiosyncratic tweak to standard Perl 6): https://github.com/rakudo-p5/v5/blob/master/README

Gotchya. Just to be clear for any others reading along: * One can run (a subset of) Perl 5 code directly on any of the Rakudo backends (thus even on the JVM) by using v5, a Perl 5 compiler written in Perl 6.[1] I think it will be many years, if ever, before v5 parses all of Perl 5 and becomes a good choice for running arbitrary legacy Perl 5 code without tweaks, but it's probably going to be a key piece of technology bridging to Perl 5 in 2015. In particular, there's been talk recently of combining it with Inline::Perl5, discussed next, to provide improved sugar for P5 <-> P6 combinations.[2] * Any host that can run arbitrary C code can run just about any Perl 5 code (including modules that use XS) via libperl, an embedded version of the stock Perl 5 interpreter. Inline::Perl5 uses this approach to allow the Rakudo Perl 6 compiler to run