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