Show understanding of how an interpreter can execute programs without producing a translated version

16.2 Translation Software – Interpreters

Learning Objective

Show understanding of how an interpreter can execute programs without producing a translated version.

What is an Interpreter?

An interpreter is a type of translation software that reads a program’s source code and executes it directly, statement by statement, without first converting the whole program into an independent executable form.

Key Characteristics

• Performs lexical analysis, parsing, and execution in a single pass.
• Does not generate an intermediate object file or machine code that can be run later.
• Typically operates at a higher level of abstraction (e.g., byte‑code or abstract syntax tree).
• Provides immediate feedback, which is useful for scripting and interactive environments.

Step‑by‑Step Execution Process

1. Read source line: The interpreter fetches the next line of source code.
2. Lexical analysis: The line is broken into tokens (identifiers, literals, operators, etc.).
3. Parsing: Tokens are assembled into a syntactic structure, usually an abstract syntax tree (AST).
4. Semantic checks: The interpreter verifies type compatibility, scope rules, etc.
5. Direct execution: The AST node is evaluated immediately, performing the required operation (e.g., arithmetic, I/O, function call).
6. Repeat steps 1‑5 until the end of the program is reached or a termination condition occurs.

Illustrative Pseudocode of an Interpreter Loop

while not endofsource:
line = readnextline()
tokens = lexical_analyse(line)
ast = parse(tokens)
evaluate(ast)   # immediate execution

Comparison with a Compiler

Why No Separate Translated \cdot ersion?

The interpreter keeps the program in its original textual form throughout execution. Each statement is parsed and evaluated on the fly, so there is never a stage where the whole program exists as a distinct machine‑code image. This design eliminates the need for a separate linking step and allows the interpreter to:

• Maintain a live mapping between source lines and runtime actions (useful for debugging).
• Adapt to dynamic features such as eval or runtime code generation.
• Execute code entered interactively (e.g., REPL environments).

Performance Considerations

The runtime cost of an interpreter can be expressed as:

\$T{\text{total}} = \sum{i=1}^{n} \bigl(T{\text{lex}}(i) + T{\text{parse}}(i) + T_{\text{exec}}(i)\bigr)\$

where \$n\$ is the number of statements, and \$T{\text{lex}}\$, \$T{\text{parse}}\$, \$T{\text{exec}}\$ are the times for lexical analysis, parsing, and execution of each statement respectively. In contrast, a compiled program incurs \$T{\text{lex}}\$, \$T{\text{parse}}\$, and \$T{\text{codegen}}\$ once during compilation, after which \$T_{\text{exec}}\$ is typically much smaller.

Typical Use Cases

• Scripting languages (Python, Ruby, PHP)
• Educational environments where immediate feedback is valuable
• Rapid prototyping and testing of algorithms
• Command‑line shells and interactive consoles

Suggested Diagram

Key Take‑aways

• An interpreter executes programs directly without producing a separate translated version.
• The interpreter repeats the translation steps for each statement at runtime.
• This approach offers high portability and rapid development but incurs a performance penalty compared with compiled code.