What is the industry definition of an interpreter (as opposed to a compiler)?

Question

In my compiler design courses, I have learned about and worked with a clear academic definition of an interpreter and a compiler, with an interpreter being

a program Pi from a language M capable of taking a program i from a language I and an input and executing i with the given input and the correct semantics for I on a machine capable of running programs from M

and a compiler being

a program Pc that, when given a valid program i from a language I as an input, produces a semantically equivalent program o in a language O

This definition would clearly put the usual execution of Java bytecode by a JVM in the domain of interpretation, no matter how much JIT compilation is done. (Of course, Java is also compiled before, from Java code to Java bytecode.) I have encountered opinions in discussions on this site that clearly and vehemently state the opposite, i.e. that Java Bytecode execution thingies are compilers. Since I am about to make the leap from academics to industry, I am a little bit confused here:

Is the above definition of interpreters false from the viewpoint of industry people in general? Or is it just false for Java people? Is the view of Java as a fully compiled language an alternate, but minority view? Or just a few loonies?

(PS: Please do not move this to cstheory. I have deliberately put this question here since I would really like to get the view of the professional industrial, not the academic community.)

Answer 1

This definition would clearly put the usual execution of Java bytecode in the domain of interpretation, no matter how much JIT compilation is done. I have encountered opinions in discussions on this site that clearly and vehemently state the opposite, i.e. that Java Bytecode execution thingies are compilers.

Well, the two definitions aren't mutually exclusive. An interpreter can contain a compiler (in fact, most modern interpreters contain at least a bytecode compiler).

But I think the intuitive definition most people here use is something like:

• a compiler creates native code that is then run directly by the CPU
• an interpreter has some kind of "interpreter main loop" that reads instructions (either source code statements or something like precompiled P-Code or bytecode) and performs instructions accordingly.

By this distinction, an "interpreter" is usually an order of magnitude slower than a "compiled" program. So when we're talking about performance, this definition is more useful than the classic CS definition.

Answer 2

From Michael Scott's Programming Language Pragmatics, Third Edition.

The high-level explanation of compilation is:

The compiler translates the high-level source program into an equivalent target program (typically in machine language), and then goes away. At some arbitrary later time, the user tells the operating system to run the target program. The compiler is the locus of control during compilation; the target program is the locus of control during its own execution.

A high-level explanation for interpretation is:

Unlike a compiler, an interpreter stays around the the execution of the application. In fact, the interpreter is the locus of control during that execution. In effect, the interpreter implements a virtual machine whose "machine language" is the high-level programming language. The interpreter reads statements in that language more or less one at a time, executing them as it goes along.

However, some language implementations also mix compilation and interpretation, so the lines get a little more blurry. In such an instance, the source program is translated into an intermediate program that is run by a virtual machine. The source code is compiled, and the output of compilation is interpreted.

Compilation happens when a translator thoroughly analyzes the input source files and creates some output that does not resemble the original source. That means that compilation requires, according to Scott, "analysis and nontrivial transformations".

Answer 3

Is the above definition of interpreters false from the viewpoint of industry people in general?

No

Or is it just false for Java people?

No

Is the view of Java as a fully compiled language an alternate, but minority view?

No

Or just a few loonies?

No

The Java execution environment is more complicated than is envisaged by those theoretical CS definitions. But both theoreticians and practical developers are cool with this.

Theoretical definitions like these are designed for a particular purpose; i.e. formal reasoning about how programs are "compiled" and "run". If you need to model Java in that way, and include JIT compilation in the modelling, then there are ways to handle this. For instance you could make "call native compiled method" a primitive operation of the interpreter.

The reality is that the Java execution platform uses both compilation and interpretation in both the intuitive and theoretical sense. So if you need to model the Java platform to that level of detail, you need to incorporate this into the modelling.

Answer 4

I generally consider any program that parses and converts code into a lower level form a compiler. So I'd definately consider Java a compiler. As would be C#, Python, PHP, etc compilers, as they all reduce source code down to bytecode, which is then executed. C++, Delphi, and a few others that compile directly to natively executed code I'd call (and I see a lot of people call) 'native code compilers'.

An interpreter, at least the way I learned it way back when, is a program that parses lines of a script one at a time and executes them directly. That is, there's no intermediate or lower level code. I'm not aware of any 'modern' languages that are interpreters.

Regarding your definition of 'compiler', I dont think that necessarily implies that Java code isnt compiled. You just need to interpret 'language O' as the bytecode instruction set.

Answer 5

From practical point of view you can think that something is interpreted as soon as you can do this pseudo code:

a = 6
b = 7
eval("c = a + b")
print c

I will not discuss security issues, best practices when to use and when not to use eval and so on.

JVM and .NET allows (with some call to standard library functions, wrappers and other issues) to compile code on the fly:

a = 6
b = 7
assembly = my_implementation_of_eval("function sum(x,y) { return x + y} ")
print assembly.call("sum",a,b);

But that is just a compiler with ability to dynamically load a module. Compare deep integration to local vars and creating new variables in interpreter.

Answer 6

A Compiler usually translates something from language A to language B. Language B can be machine code (for an existing or virtual CPU), but there are compilers that output source code in a different language.

An Interpreter usually executes a program written in language X.