Page 2 of 2
NV: Can you elaborate on the x64 backend?
This is some sample code:
NV: Could RPython be considered as a possible backend , taking advantage of its JIT?
FG: Yes, and that is why there is a Python backend for Perlito6. The idea was to recode it down to the Rpython level in the next step.
from the README-perlito6 file.
NV: Very exciting stuff. How come there is no Parrot backend?
FG: There was a Parrot backend at some point, http://pastebin.com/ChSgHb0T but it is not maintained. Parrot works better now - I think it would not be too difficult to make the bootstrap at this point.
NV: What is meant by "compile Perl5 to Perl5" ?
FG: This is when you compile Perl5 to an abstract syntax tree, and then emit the AST as Perl5 code. You can use this to test if the compiler and code emitter are doing the right thing and you could potentially use this to add features to Perl5 - think of a preprocessor or macro-expander.
NV: Giving Perl5 an AST has distinct advantages over the natively produced opcode tree?
FG: No, the Perlito AST is not really better than the optree. The advantage comes from Perlito being Perl all way down so you can hack the compiler using plain Perl.
NV: And what about the Perlito 5 AST, how different is it from the Perlito 6 AST?
FG: Yes, it is just a bit different. Compare :
I think the differences at the AST level are pretty minor - there are more differences at the semantic level
NV: How much effort would be required to transform that AST to a (Linq) Expression Tree, like IronJS does, hence hook into the DLR and take advantage of .NET's GC, threading, JIT and libraries?
FG: Note the comment:
"However, IronJS does not use these binders as they are slow".
It is probably easy to make a simple port for bootstrapping but you need to take the time to optimize for the platform. It would take probably a couple weeks of work for the initial proof of concept.
NV: Talking about .NET there was also a IronPython backend. What is the state of that ?
FG: It looks like as pypy supports the CLI, IronPython is a bit behind but I haven't followed closely. The IronPython backend for Perlito6 was quite slow.
FG: You can try it out at :
There is also a Perl6 version, but that is quite behind, because I've spent most of the past year working on the Perl5 compiler.
There are a few features specific to the js backend, such as
This comes from the Pugs-js implementation.
The compiler supports perl objects, simple regexes, as well as more "advanced" features like tied arrays. There is also a more complete js backend, the 'js3' version - which emulates more closely Perl5 but that comes at a performance price.
NV: The saying goes 'only perl can parse Perl'. Does it hold true for Perl6 as well?
FG: You need Perl at some stages of the compilation, BEGIN blocks is an example. For simple programs you can work around - you just need to keep track of what the compiler have seen so far, like subroutine signatures, for example.
Perl6 has been designed to be easier to parse but it makes sense to parse Perl6 using Perl6, so most compilers just do it.
NV: As an industry insider working for one of the biggest Perl5 advocates (if not the biggest) do you think that an organization of such a size would someday consider switching from Perl5 to Perl6?
When would the setting be mature enough for such a switch?
FG: It will eventually happen. At some point people will use it for one-off scripts, and then somebody will use it on a cronjob, but it will not replace Perl5 in this environment - it will instead compete with alternate languages, like Go.
NV: What could be the problem domain that Perl6 would be good at solving thus benefiting a business like Booking.com. In particular, would it be good at handling Big Data ?
FG: That would be a nice niche, yes. This is one place where Perl6 would compete with Go, for example.
NV: Lately there is a lot of discussion on optimizing Perl5 or focusing on experimental versions like p2,p11 or Moe. Is that an indication that Perl5 has reached its boundaries , performance wise?
FG: No, Perl5 is still being optimized at each new release but there are new technologies that people need to try out, and for big changes it is easier to start from scratch - this is good for experimenting.
NV: So what are Perlito's potential uses for developers and end-users alike?
FG: The main product for end-users are the Perl-js compilers. They can be integrated in other projects, like azawawi++ did with the Farabi web-based IDE.
For developers there are a lot of possibilities. Perlito is pretty open to hacking, there are no hard coded limits
NV: Finally, what are your expectations for the future?
FG: The Perlito5::X64::Assembler package should allow for building an efficient, Perl-specific environment. At some point, if this becomes the main development platform for Perlito, we don't need to work around virtual machine limitations anymore.
The other side of the Perlito development is to allow better Perl5/Perl6 inter-operation;there is already a Perl6-to-Perl5 compiler in CPAN :
This is based on Perlito6. The plan is to finish the Perl5-to-Perl6 compiler, that would work about the same way as v6.pm.