Perlito, the open source compiler collection that implements a Perl5 and a Perl6 compiler has just launched a brand new Java backend. It seemed a good time to catch up with the project by talking to its lead contributor, Flavio Glock.

Last time I interviewed Flavio Glock about Perlito was back in 2013 when the project was in its first steps. At that time Perlito could compile Perl 5 or Perl 6 programs into various backends,  including JavaScript, Python, Ruby and Go, but it was also designed with extensibility from the ground up so it could be further extended to other backends in the future.

Well this time has come, with Flavio just announcing a brand new Java backend! In those 4 years the project has really taken off, a lot has changed, and given the opportunity of this new and great development I thought that a follow up was in order.

Flavio was once more deeply insightful and provided links to three very interesting video presentations on the topic that took place during last year's AmsterdamX Perl Mongers gathering. They've been included at the end of the interview, so make sure that you check them out!

NV: So Flavio, back in 2013 Perlito's definition was:

a compiler collection that implements a subset of Perl5 and Perl6

Are we still talking about a subset, and in any case what percentage of Perl can be now mapped to Java? 

FG: At this stage, Perlito5 sees itself more like a "Perl port" within which Perlito5-Java and Perlito5-JavaScript would be “platforms”. Many of the missing features are due to platform differences, rather than “not yet implemented”.

All of the Perl syntax can be mapped to Java. Specific functions are prioritized to be implemented first - either because they are more useful, or because it is low-hanging-fruit. 

All Perl types are supported - scalar, array, hash, closure, regex, typeglobs, references and objects; as well as declarations - my, our, state, local. “require” was just implemented (after the release); “tie”, “overload” are work-in-progress.

Error messages are hard to replicate exactly. This is slowly improving. 

NG: What is left out? 

FG: XS is left out. XS is Perl foreign function interface through which a program can call a C or C++ subroutine - this doesn’t work (not natively) in the JVM environment.

• many CPAN modules that use C libraries don't work
• some CPAN modules are already ported, see: Perlito5 - java - native types wip

The ported Digest::MD5, Digest::SHA1, and MIME::Base64 modules are neat, because there are Java APIs that could be used almost straight out of the box.

List::Util, Scalar::Util, and Encode.pm are not so clean - these involve some low level (Java) stuff.

XS is very interesting, but it is also very complicated. Supporting pure Perl allows Perlito to have completely different calling convention and internal data structures, optimized for JVM.  

NG: What cannot be done? 

FG: DESTROY is not done. While we could track object lifetimes, this is just not the way the JVM works. Even if you don’t use DESTROY directly, you will notice other problems:

• files don't "auto-close" at the end of a block
• weaken() is a no-op
• Try::Tiny "finally" doesn't work
• Object::InsideOut will not cleanup unused objects 

NV: Can Java’s C#'s IDisposable pattern equivalent in AutoClosable come into play? 

FG: The dispose pattern doesn’t help here, because a file handle can survive the block where it was created. For example, if a file is open at object creation and the handle is stored in the object. Also, many UNIX (and Windows, even) features are not available. In particular:

• file permissions for setuid, setgid, and sticky bit are not implemented
• some signals are not available in Java. 

NV: Is Java8 supported and if so how would a Perl function end up as a Lambda expression? 

FG: Perlito supports Java 8 but is affected by a Java 8 bug that slows down Java compilation (“type inference exponential compilation performance“). Perlito5 compiles with the javac option "-source 7" as a workaround for this bug and a Perl subroutine becomes an anonymous inner class. This means we cannot use Lambda expressions just yet. There are reports that this is fixed in Java 9, so the workaround can go away soon and when migrating to Java 9 anonymous inner classes will be replaced by Lambda. Fortunately, Perl closures work just fine with inner classes for now. 

NV: You also mention "eval-string", can you elaborate? 

FG: Yes, Java does provide an API for compile tools (not the Scripting API), this was introduced in Java 6. We combine this with an in-memory “file system” (actually just a hash) and a custom class loader, and we have eval-string. This was constructed on top of the work of other people who figured out the details before me; see Credits in the module.  

NV: Under Thread safety it states:

Perl global variables are shared between threads.

Is that a shift from Perl5's internal threading model where a full copy is cloned thus nothing gets shared?

FG: Threads in Perlito5 are not mature. The “threads” module from Perl is marked as “discouraged”, so we are not going to have that. Plain Java threads can be used, but the API is a bit awkward. We will probably end up with something Perl6-like - this needs more experimentation.  

NV: Is the Java backend's main purpose of running Perl5 on Android devices? 

FG: This is not clear yet, Perlito5 is now a pure Perl implementation, without system-specific extensions. It would be nice to have an Android-specific distribution. Yati Sagade gave an AmsterdamX talk about our hackathon experiment last year, and you can read the the hackathon report in my blog. 

We need to extract the parts that are interesting for Android, remove some Java SE-specific features, and add helper modules for the Android GUI.Most likely Perlito5 for Android would have eval-string disabled, for security reasons.

We also had a AmsterdamX presentation about using Perlito5 in Hadoop, but unfortunately we lost the recording. This is a sample of code to access HBase, by Bosko Devetak.

This is what a GUI application might look like. Note that it requires some Java::inline - that’s not a good thing, I think it can be improved. We are doing these experiments to see what we need to add on top of the pure Perl implementation to make it usable in these different environments.

NV: On a side note, how is the Perl6 support evolving?

FG: The news is on the Perl 5 to 6 translation. With support for BEGIN blocks, we can now preprocess source code to a “pure” syntax tree that doesn’t contain Perl 5 code: all “use”, “import” work is done before the translation. For example, this code creates 3 subroutines at compile-time:

perl perlito5.pl -Isrc5/lib -Cperl5 -e ' BEGIN { for my $v (3..5) { *{"v$v"} = sub { $v } } }  '

The AST to Perl6 translation still needs work, to reflect all the new features introduced since this project started.

NV: Back in 2013 we talked about the "Perlito5::X64::Assembler package which should allow for building an efficient, Perl-specific environment. You said:

"At some point, if this becomes the main development platform for Perlito, we don't need to work around virtual machine limitations any more."

What is the state of that and if utilized could be used as way for Perlito to emit WebAssembly compatible bytecode for the browser environment instead of Javascript?

FG: There is no activity at the X64 backend at the moment. The plan was to use an inline assembler, and work it out from there. This is a pure Perl assembler, based on the V8 engine.

You can try the experimental code using:

perl -I src5/lib  misc/t5-x64/01_sanity.t

A similar assembler was also planned for compiling JVM bytecode, but this was not necessary. Instead, the JVM port is based on the Java_eval experiment.

Another, a little more higher-level approach was the “Pitu” experiment. This was about implementing eval-string in C. It didn’t get far because of uncertainty about tinycc, the last release of which was 4 years ago.

WebAssembly looks good, I like the s-expressions idea. I hope they go ahead with the plan to add garbage collection, it would help a lot.

More Information

Perlito on GitHub

Perlito5 Java backend

Related Articles

Perlito - 2013 Interview With Flávio Glock (as part of the trilogy on implementations of Perl 6)

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info