Hi,
On 06.12.2014 18:55, Mayuresh Kathe wrote:
Hello,
I have been reading up (a bit) on Perl6 and found most articles
mentioning Parrot + Rakudo as the primary tools for development using
the language.
Well, these days we have three backends (MoarVM, JVM and Rakudo).
Is there any rationale for going with the above approach instead of an
interpreter based one?
First of all, the lines between interpreters and compilers a bit blurry.
People think of Perl 5 as an interpreter, but actually it compilers to
bytecode, which is then run by a runloop. So it has a compiler and an
interpreter stage.
Rakudo does the same, except that it also adds the ability to serialize
the byte code to a file. (At least for modules; doesn't work for scripts).
Apart from the usual trade-offs between compilers and interpreters,
there's a Perl 6 specific reason. There are lots of pieces from the
compiler that must behave like Perl 6 code. For example you must be able
to extend the grammar that parses Perl 6 with Perl 6 regexes. The
compiler must provide the built-in types and routines, all with the
usual Perl 6 calling conventions, with Perl 6 type constraints etc.
And these things are much easier to achieve if you have some degree of
self-hosting, that is, stuff is implemented in Perl 6 (or a subset
thereof). And for self-hosting, a compiler tends to be a better choice,
because you can store the byte code and use it as a base for
bootstrapping. Maybe it's just my lack of imagination, but I have
trouble imagine a sane and fast bootstrapping mechanism for interpreters.
Also, would there be community acceptance of an interpreter written in
portable c89 for Perl6?
Oh yes!
We've had many lucky periods where more than one compiler was actively
developed (any(pugs, kp6 (now perlito), rakudo, niecza)), which lead to
friendly competition, fresh ideas and generally lots of fun.
Cheers,
Moritz
