Interpreter (computer)

In computer science, interpreter or interpreter is a computer program capable of parsing and executing other programs. Interpreters differ from compilers or assemblers in that while they translate a program from its description in a programming language to system machine code, interpreters only perform the translation as needed, typically on an instruction-by-instruction basis., and normally do not save the result of said translation.

Using an interpreter, a single source file can produce the same results even on vastly different systems (eg a PC and a PlayStation 4). Using a compiler, a single source file can produce the same results only if it is compiled into different system-specific executables.

Interpreted programs are usually slower than compiled ones due to the need to translate the program while it runs, but in return they are more flexible as programming and debugging environments (which translates, for example, into easier to replace entire parts of the program or to add entirely new modules), and allow the interpreted program to be offered an environment that does not depend on the machine where the interpreter is running, but rather on the interpreter itself (commonly known as a virtual machine).

To improve performance, some implementations of some programming languages may interpret or compile the original source code into a more compact intermediate form, and then translate that into machine code (eg Perl, Python, MATLAB, and Ruby). Some accept source files saved in this intermediate representation (eg Python, UCSD Pascal, and Java).

Currently, one of the most common environments for interpreters to use is in web browsers, due to the possibility that these have to run independently of the platform.

Bytecode interpreters

There is a spectrum of possibilities between interpretation and compilation, depending on the amount of parsing done before the program is executed. For example, Emacs Lisp is compiled to bytecode, which is a highly compressed and optimized representation of the Lisp source code, but it is not machine code (and therefore not tied to any particular hardware). This bytecode is then interpreted by a bytecode interpreter (which is written in C). In this case, the compiled code is the machine code for a virtual machine, which is not implemented in the hardware, but in the bytecode interpreter. The same approach is used with the Forth code used in Open Firmware systems: the source language is compiled into "F code" (one bytecode).

Efficiency

The main disadvantage of interpreters is that when a program is interpreted, it typically runs slower than if it had been compiled. The difference in speeds can be minuscule or large; often an order of magnitude and sometimes more. It generally takes more time to run a program under an interpreter than it does to run the compiled code, but it may take less time to interpret than the total time required to compile and run it. This is especially important if you are making and testing prototype code when an interpreter's edit-interpret-debug cycle can often be much shorter than the compiler's edit-compile-run-debug cycle.

Code interpretation is slower than compiled code execution because the interpreter must parse each statement in the program each time it is executed and then perform the desired action, whereas compiled code only performs the action within a certain context fixed by compilation. This analysis at run time is known as "interpretive overhead". In an interpreter, access to variables is also slower because the mapping of identifiers to storage locations must be done repeatedly at runtime rather than at compile time. There are several trade-offs between development speed using an interpreter and execution speed using a compiler. Some systems (eg, some LISPs) allow interpreted and compiled code to call each other and share variables. This means that once a routine has been tested and debugged under the interpreter it can be compiled and therefore benefit from faster execution while other routines are being developed. Many interpreters do not execute the source code as is but instead convert it into a more compact internal form. For example, some BASIC interpreters replace keywords with single-byte tokens that can be used to find the instruction in a branch table. An interpreter may well use the same lexicator and parser as the compiler and then interpret the resulting abstract syntax tree.

Abstract Syntax Tree Interpreters

In the spectrum between interpretation and compilation, another approach is transforming the source code into an optimized abstract syntax tree (AST), and then proceeding to execute the program following this tree structure. In this approach each statement needs be parsed only once. As an advantage over bytecode, AST maintains the overall program structure and relationships between statements (which are lost in a bytecode representation), and provides a more compact representation.

Thus, AST has been proposed as a better intermediate format for just-in-time compilers than bytecode. Also, it allows for better analysis during runtime. An AST-based Java interpreter has been shown to be faster than a similar bytecode-based interpreter, thanks to the more powerful optimizations enabled by having the complete program structure, as well as high-level data types, available at runtime.

Just in time compilation

To further blur the distinction between interpreters, bytecode interpreters, and compilation, there is just-in-time (or JIT) compilation, a technique in which the intermediate representation is compiled to native machine code at runtime.. This confers the efficiency of running native code, at the cost of startup time and increased memory usage when the bytecode or AST is first compiled. Adaptive optimization is a complementary technique in which the interpreter performs a performance analysis of the running program (profiling) and compiles its most frequently executed parts to native code. Both techniques are a few decades old, appearing in languages such as Smalltalk in the 1980s.

In recent years, just-in-time compilation has gained the attention of most programming language implementers, with Java, Python, and the Microsoft.NET Framework all now including JITs.

Examples

Some examples of interpreters:

• Zend motor
• CPython
• Ruby MRI
• YARV
• on:Basic

Interpreted language

An interpreted language is a programming language for which most of its implementations execute the instructions directly, without prior compilation of the program to machine language instructions. The interpreter executes the program directly, translating each statement into a sequence of one or more subroutines already compiled into machine code.

The terms interpreted language and compiled language are not well defined because, in theory, any programming language can be interpreted or compiled. It is increasingly popular, in more modern implementations of a programming language, to offer both options.

Interpreted languages can also be differentiated from machine languages. Functionally, both execution and interpretation mean the same thing - getting the next instruction/statement from the program and executing it. Although interpreted bytecode is also identical to its machine code form and has an assembly representation, the term "interpreted" is in practice reserved for languages "processed by software" (such as virtual machines or emulators) over native processing (for example, by hardware).

In principle, the programs of many languages can be compiled or interpreted, emulated or executed natively, so this designation applies only to the most common practical implementation, rather than representing an essential property of the language. Similar to processor microcode, many interpreters internally fall back on runtime compilation.

By avoiding compilation, interpreted programs are easier to evolve during development and execution (sometimes morphing from one to the other). On the other hand, since compilation involves translation into a more machine-friendly format, interpreted programs run slower and less efficiently (ie, they use considerably more power). This is especially true for scripted languages, whose statements are more complex to parse than machine instructions.

Many languages have been implemented using both compilers and interpreters, including BASIC, C, Lisp, Pascal, and Python. Java and C# are compiled to bytecode, the interpreted language specific to the virtual machine. Many Lisp implementations are free to mix compiled and interpreted code.

Historical Background on Interpreting and Compiling

In the early days of computing, language design was heavily influenced by the decision to use compilation or interpretation as the execution modes. For example, some compiled languages require programs to explicitly indicate the data type of a variable when it is declared or when it is first used, while some interpreted languages take advantage of the dynamic aspects of interpretation to make such unnecessary statements. For example, Smalltalk (1980), which was designed to be interpreted at runtime, allows generic objects to interact dynamically with each other.

Initially, interpreted languages were compiled line by line, that is, each line was compiled as it was about to be executed, and if a loop or subroutine caused certain lines to be executed multiple times, they would be recompiled repeatedly.. This has become much less common. Most interpreted languages use an intermediate representation, which combines both compilation and interpretation. In this case, a compiler can produce the bytecode or threadedcode, which is then executed by a bytecode interpreter.

Examples include:

• Java
• Python
• Ruby (likely, uses an abstract syntax tree as an intermediate representation)
• Forth

The intermediate representation can be compiled once (as in Java), each time it is to be executed (as in Perl or Ruby), or each time a source code change is detected before execution (as in Python).

Advantages of interpreting a language

Interpreting a language gives implementations additional flexibility over compiled implementations. Some features are easier to implement in interpreters than in compilers are (but are not limited to these):

• Independence of the platform (e.g. Java bytecode)
• Reflection and reflexive use of the evaluator (e.g. a first order eval function)
• Dynamic types
• Smaller program size (since implementations have the flexibility to choose the set of instructions)
• Dynamic environment
• Facility in depuration (it is easier to get source code information in interpreted languages)

Disadvantages of Interpreted Languages

The main disadvantage of interpretation is a much slower program execution speed, compared to direct execution of machine code on the computer's CPU. One technique used to improve performance is runtime compilation, which converts frequently executed sequences into computer machine code.

List of most used languages in interpreted form

• APL A vector-oriented language that uses an unusual character set
  • J A variant in which the tacit definition offers some of the benefits of the compilation
• BASIC (although the original version was compiled, as well as many modern)
  • thinBasic
• ECMAScript
  • ActionScript (version 3.0 is not interpreted, so the function eval() was removed)
  • E4X (ECMAScript for XML)
  • JavaScript (first called MochaAnd then LiveScript)
  • JScript
• Handling of equations and resolution systems
  • GNU Octave
  • IDL (Interactive Data Language)
  • TK Solver
  • Mathematica
  • MATLAB
• EUPHORIA interpreted or compiled
• Forth
• Game Maker Language
• Java (schedule)
• Madness Script
• Perl
• PHP
• PostScript
• Python
• Lisp
• Logo
• Scheme
• MUMPS (traditionally interpreted, compiled in modern versions)
• REXX
• Ruby
  • JRuby (a Java implementation of Ruby)
• Seed7 interpreted or compiled
• Smalltalk
  • Bistro
  • Dolphin Smalltalk
  • F-Script
  • Little Smalltalk
  • Squeak
  • VisualAge
  • VisualWorks
• Language scripting
  • WebDNA
• Calculation sheets
  • Excel stores formulas, and interprets them from a symbolic format
• S
  • R
• Tcl
  • XOTcl
• VBScript
• PowerShell
• XMLmosaic Archived on 2 August 2009 in Wayback Machine. A programming language interpreted similar to C# written in Visual Basic.NET

Languages normally compiled to bytecode

Many interpreted languages are first compiled to bytecode, which is then normally interpreted by the virtual machine using runtime compilation, from bytecode to native code. However, sometimes the bytecode can also be compiled to a native binary using an Ahead-of-time compilation compiler, or executed natively by the hardware processor.

• Java (combined in Java byte code to be played by JVM)
  • Groovy
  • Join Java
  • ColdFusion
  • Scala
• Lua
• .NET Framework (translated to byte code, called CIL)
  • C/C++
  • C#
  • Visual Basic.NET
• Pike
• Python
• Squeak Smalltalk
• Visual FoxPro
• Lisp
• AppleScript