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/> >
