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.de>Cc: perl6-us...@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/> > >
