Rationale for a VM + compiler approach instead of an interpreter?
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. Is there any rationale for going with the above approach instead of an interpreter based one? Also, would there be community acceptance of an interpreter written in portable c89 for Perl6? Best Regards, ~Mayuresh
Re: Rationale for a VM + compiler approach instead of an interpreter?
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
Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
* Moritz Lenz mor...@faui2k3.org [2014-12-06 20:05]: 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. This is sort of a tangent, but it was a clarifying insight that resolved a point of vagueness for me, so I’d like to just talk about that for a moment if you’ll indulge me. Namely, that line is actually very clear in a theoretical sense, if you judge these types of program by their outputs: Interpreter: A program that receives a program as input and produces the output of that program as output Compiler: A program that receives a program as input and produces another equivalent (in some sense) program as output Now some compilers emit programs that can be run directly by the CPU of the same computer that is running them, without an extra interpreter. This is what people with fuzzy ideas of the terms usually refer to when they speak of a compiler. But the output doesn’t have to be a program of this kind. The blurriness in practice comes from the fact that essentially all programming languages in use by humans are very impractical to use for direct interpretation. And so almost every interpreter ever written is actually coupled to a compiler that first transforms the user source program into some other form which is more convenient to interpret. Even the BASICs on those famous old home computers of the past are combined compiler-interpreters in this sense. Basically just parsing an input program up front as a whole essentially meets the definition of a compiler – even if a rather weak version of it. I think that means shells are typically true interpreters, and that they are more or less the only real examples of such. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Rationale for a VM + compiler approach instead of an interpreter?
On 2014-12-07 00:31, Moritz Lenz wrote: 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. Great. And thanks for the detailed response. I am training for computer science, and as a rite of passage, my mentor + guide has asked me to write either an interpreter or a compiler for any language of my choice. Would prefer to work on Perl6. ~Mayuresh
