Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
* Parrot Raiser 1parr...@gmail.com [2014-12-07 22:40]: The practical distinction, surely, is that the output of a compiler is usually kept around, to be run one or more times, whereas the an interpreter always works with the original human-readable source. Yes, surely that’s it. We all consider Python a compiler, after all. :-) Go on, tweak your definition to pin it down. :-) * Gerard ONeill oobl...@usa.net [2014-12-08 15:10]: How about an interpreter interprets input directly into action (even if there is some optimization going on), while a compiler converts instructions from one set to another set to be interpreted later. That’s just an unnecessarily concrete rephrasing of the definitions I mentioned. Which would make perl both at the perl source level, Perl never interprets raw perl code without first parsing it into an optree. and an interpreter at the bytecode level. Well yeah, bytecode always implies an interpreter. Thinking of execution as interpretation, this allows for the transmeta concept, where the CPU was just an interpreter / just in time compiler that interpreted x86 instructions. Although modern CISC CPU's have a step where the input to the chip was still converted to microcode which was actually what was run. So a compilation step, and an interpreting step. Execution takes a program as input and produces the program’s output as output. So it’s interpretation. By definition. Sometimes there are dedicated hard-wired circuits that do it, and sometimes there are other layers of abstraction around the hard-wired circuitry. The layers can be in hardware, and even then at different degrees of abstraction (FPGA vs microcode, say), or in software, and really what is software and what is hardware depends merely on your perspective. There are plenty of coprocessors that internally run code which is opaque from the outside; is that software or hardware? That’s what I meant by fuzzy ideas. You don’t get anywhere trying to nail this pudding to the wall. You only get somewhere if you accept that which is which is relative to your point of view and that the difference is defined in terms of the output: compilers transform programs to other programs and interpreters transform a program into its output. That’s it. E.g. if you have something perl running a Perl program then you have the CPU interpreting a program (perl) that itself interprets another program (the optree), which in turn was compiled from the user Perl program earlier on. Once you stop trying to artificially force everything into a single absolute distinction, the entire debate about which is which vanishes. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
Looks like we have a different way of thinking, not to mention thinking about a particular idea. Obviously definitions and distinctions are only for those who care about them, and everyone else is free to ignore them so that there is no debate. Although if I'm not mistaken, it seems like we agree (minus perhaps my misunderstanding of how perl handles begin and end blocks, or bytecode..). G. -- Original Message -- Received: 08:32 AM EST, 12/10/2014 From: Aristotle Pagaltzis pagalt...@gmx.de To: perl6-users@perl.org Subject: Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?] * Parrot Raiser 1parr...@gmail.com [2014-12-07 22:40]: The practical distinction, surely, is that the output of a compiler is usually kept around, to be run one or more times, whereas the an interpreter always works with the original human-readable source. Yes, surely that’s it. We all consider Python a compiler, after all. :-) Go on, tweak your definition to pin it down. :-) * Gerard ONeill oobl...@usa.net [2014-12-08 15:10]: How about an interpreter interprets input directly into action (even if there is some optimization going on), while a compiler converts instructions from one set to another set to be interpreted later. That’s just an unnecessarily concrete rephrasing of the definitions I mentioned. Which would make perl both at the perl source level, Perl never interprets raw perl code without first parsing it into an optree. and an interpreter at the bytecode level. Well yeah, bytecode always implies an interpreter. Thinking of execution as interpretation, this allows for the transmeta concept, where the CPU was just an interpreter / just in time compiler that interpreted x86 instructions. Although modern CISC CPU's have a step where the input to the chip was still converted to microcode which was actually what was run. So a compilation step, and an interpreting step. Execution takes a program as input and produces the program’s output as output. So it’s interpretation. By definition. Sometimes there are dedicated hard-wired circuits that do it, and sometimes there are other layers of abstraction around the hard-wired circuitry. The layers can be in hardware, and even then at different degrees of abstraction (FPGA vs microcode, say), or in software, and really what is software and what is hardware depends merely on your perspective. There are plenty of coprocessors that internally run code which is opaque from the outside; is that software or hardware? That’s what I meant by fuzzy ideas. You don’t get anywhere trying to nail this pudding to the wall. You only get somewhere if you accept that which is which is relative to your point of view and that the difference is defined in terms of the output: compilers transform programs to other programs and interpreters transform a program into its output. That’s it. E.g. if you have something perl running a Perl program then you have the CPU interpreting a program (perl) that itself interprets another program (the optree), which in turn was compiled from the user Perl program earlier on. Once you stop trying to artificially force everything into a single absolute distinction, the entire debate about which is which vanishes. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
How about an interpreter interprets input directly into action (even if there is some optimization going on), while a compiler converts instructions from one set to another set to be interpreted later. Which would make perl both at the perl source level, and an interpreter at the bytecode level. Thinking of execution as interpretation, this allows for the transmeta concept, where the CPU was just an interpreter / just in time compiler that interpreted x86 instructions. Although modern CISC CPU's have a step where the input to the chip was still converted to microcode which was actually what was run. So a compilation step, and an interpreting step. -- Original Message -- Received: 04:37 PM EST, 12/07/2014 From: Parrot Raiser 1parr...@gmail.com To: Aristotle Pagaltzis pagalt...@gmx.deCc: perl6-users@perl.org Subject: Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?] The practical distinction, surely, is that the output of a compiler is usually kept around, to be run one or more times, whereas the an interpreter always works with the original human-readable source. The distinction mattered a lot more when compiling even a trivial program involved at least the order of minutes. Then, it was important to re-use the binary, to avoid recompiling for as long as possible. (Although even in the 1970s, a report-writer program could be run from source without noticeable delay.) Now, the compilation phase is usually trivial in comparison to run times, for any significant data set. Perl 6 just needs a spot of optimisation in the compile phase. :-)* On 12/6/14, Aristotle Pagaltzis pagalt...@gmx.de wrote: * 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: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
The practical distinction, surely, is that the output of a compiler is usually kept around, to be run one or more times, whereas the an interpreter always works with the original human-readable source. The distinction mattered a lot more when compiling even a trivial program involved at least the order of minutes. Then, it was important to re-use the binary, to avoid recompiling for as long as possible. (Although even in the 1970s, a report-writer program could be run from source without noticeable delay.) Now, the compilation phase is usually trivial in comparison to run times, for any significant data set. Perl 6 just needs a spot of optimisation in the compile phase. :-)* On 12/6/14, Aristotle Pagaltzis pagalt...@gmx.de wrote: * 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/
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/
