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