Migrating Perl 5 code to Perl 6

Examine the issues you may encounter when porting Perl 5 programs to Perl 6.
209 readers like this
209 readers like this
Perl 6 logo butterfly

Larry Wall. GNU General Public License or Artistic License 2

Whether you are a programmer who is taking the first steps to convert your Perl 5 code to Perl 6 and encountering some issues or you're just interested in learning about what might happen if you try to port Perl 5 programs to Perl 6, this article should answer your questions.

The Perl 6 documentation already contains most (if not all) the documentation you need to deal with the issues you will confront in migrating Perl 5 code to Perl 6. But, as documentation goes, the focus is on the factual differences. I will try to go a little more in-depth about specific issues and provide a little more hands-on information based on my experience porting quite a lot of Perl 5 code to Perl 6.

How is Perl 6 anyway?

Very well, thank you! Since its first official release in December 2015, Rakudo Perl 6 has seen an order of magnitude of improvement and quite a few bug fixes (more than 14,000 commits in total). Seven books about Perl 6 have been published so far. Learning Perl 6 by Brian D. Foy will soon be published by O'Reilly, having been re-worked from the seminal Learning Perl (aka "The Llama Book") that many people have come to know and love.

The user distribution Rakudo Star is on a three-month release cycle, and more than 1,100 modules are available in the Perl 6 ecosystem. The Rakudo Compiler Release is on a monthly release cycle and typically contains contributions by more than 30 people. Perl 6 modules are uploaded to the Perl programming Authors Upload Server (PAUSE) and distributed all over the world using the Comprehensive Perl Archive Network (CPAN).

The online Perl 6 Introduction document has been translated into 12 languages, teaching over 3 billion people about Perl 6 in their native language. The most recent incarnation of Perl 6 Weekly has been reporting on all things Perl 6 every week since February 2014.

Cro, a microservices framework, uses all of Perl 6's features from the ground up, providing HTTP 1.1 persistent connections, HTTP 2.0 with request multiplexing, and HTTPS with optional certificate authority out of the box. And a Perl 6 IDE is now in (paid) beta (think of it as a Kickstarter with immediate deliverables).

Using Perl 5 features in Perl 6

Perl 5 code can be seamlessly integrated with Perl 6 using the Inline::Perl5 module, making all of CPAN available to any Perl 6 program. This could be considered cheating, as it will embed a Perl 5 interpreter and therefore continues to have a dependency on the perl (5) runtime. But it does make it easy to get your Perl 6 code running (if you need access to modules that have not yet been ported) simply by adding :from<Perl5> to your use statement, like use DBI:from<Perl5>;.

In January 2018, I proposed a CPAN Butterfly Plan to convert Perl 5 functionality to Perl 6 as closely as possible to the original API. I stated this as a goal because Perl 5 (as a programming language) is so much more than syntax alone. Ask anyone what Perl's unique selling point is, and they will most likely tell you it is CPAN. Therefore, I think it's time to move from this view of the Perl universe:

Dromecentric view

to a more modern view:

Cpannican view

In other words: put CPAN, as the most important element of Perl, in the center.

Converting semantics

To run Perl 5 code natively in Perl 6, you also need a lot of Perl 5 semantics. Having (optional) support for Perl 5 semantics available in Perl 6 lowers the conceptual threshold that Perl 5 programmers perceive when trying to program in Perl 6. It's easier to feel at home!

Since the publication of the CPAN Butterfly Plan, more than 100 built-in Perl 5 functions are now supported in Perl 6 with the same API. Many functions already exist in Perl 6 but have slightly different semantics, e.g., shift in Perl 5 magically shifts from @_ (or @ARGV) if no parameter is specified; in Perl 6 the parameter is obligatory.

More than 50 Perl 5 CPAN distributions have also been ported to Perl 6 while adhering to the original Perl 5 API. These include core modules such as Scalar::Util and List::Util, but also non-core modules such as Text::CSV and Memoize. Distributions that are upstream on the River of CPAN are targeted to have as much effect on the ecosystem as possible.

Summary

Rakudo Perl 6 has matured in such a way that using Perl 6 is now a viable approach to creating new, interactive projects. Being able to use reliable and proven Perl 5 language components aids in lowering the threshold for developers to use Perl 6, and it builds towards a situation where the sum of Perl 5 and Perl 6 becomes greater than its parts.

Elizabeth Mattijsen
Elizabeth Mattijsen has been programming for a living since 1978 in various (mostly now defunct) programming languages before she started programming in Perl 4. In 1994 she started the first commercial web site development company in the Netherlands, using Perl 5 as the main programming language. From 2003 onwards, she was involved in the rapid growth of an online Hotel Reservation service.

6 Comments

Good summary for experienced Perl programmers. I would like to give Perl 6 a start!

Wow, great post, Elizabeth!
Perl6 sounds fascinating with these new developments. Right now, I'm looking to get (back) more into programming with a new language and Julia, Nim, Crystal, Object Pascal/Lazarus (I love Pascal syntax!), Swift, Rust & Kotlin really tickle my fancy. Actually, I just signed up for "Learn and Master Julia Programing Language from Scratch" at Udemy - haven't started yet!

Now, enter Perl 6, and I'm wondering if I should pursue that first. But OTOH, I really want a statically compiled language that can spit out a fast executable to run "close to" C speeds. Isn't Perl interpreted?

Can you enlighten us a bit on Perl6's performance and what we should expect in the future -- as the codebase matures -- in terms of performance (compiler, etc.?) relative to the languages I mentioned above?

Cheers!

-Dark Matter
****
First 2 Laws of Computer Programming:
1) Never trust a program that has not been thoroughly debugged.
2) No program is ever thoroughly debugged.
****

Rakudo Perl 6 will always be an interpreted dynamic language first. But the idea is that hot code will get optimized to machine level by a JIT. Jonathan Worthington has a nice talk about that: How does deoptimization help us go faster? (http://jnthn.net/papers/2017-spw-deopt.pdf).

To answer your question: short term, I wouldn't choose Perl 6 for the speed, but for its features. Longer term (coming 2-5 years), Rakudo Perl 6 will get much faster. But I don't think it will ever be able to spit out fast executables that start running at close to "C" speeds: the dynamic nature of Perl 6 will always be a problem for that. I guess someone could make a MoarVM bytecode -> assembly port of sufficiently static Perl 6 programs in module space. But I don't see that happening anytime soon. Of course, I'd like to be proven wrong :-)

In reply to by DarkMatter

> To answer your question: short term, I wouldn't choose Perl 6 for the speed, but for its features. Longer term (coming 2-5 years), Rakudo Perl 6 will get much faster.
---

Right now, is it comparable to the latest Python or PHP7 in execution speed? Or in 2-5 years?
Perl6 definitely has some amazing features though.

Thanks for your reply.

In reply to by Elizabeth Mattijsen

I'm only aware of benchmarks comparing it to Perl 5. And depending on what you're doing, I would say that at the moment single thread Perl 6 is on par with Perl 5 in some situations, and 10x as slow as Perl 5 if you're using a lot of regexes. However, if you can parallelize your work with `race` or `hyper`, it usually is already a lot faster than Perl 5. I have no idea how the cards will be laid out 2-5 years. YMMV.

In reply to by DarkMatter

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.