|Perlito - 4 Years On|
|Written by Nikos Vaggalis|
|Monday, 22 May 2017|
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.
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?
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.
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:
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:
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.
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."
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:
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.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Monday, 22 May 2017 )|