Interpreter a.k.a. Virtual Machine

New version!

A new version of this website is available at architectural-patterns.net.

The interpreter processes or executes other programs.

Examples

Java Virtual Machine
Rule-based systems
Scripting languages, i.e. JavaScript

Where does it come from?

A.f.a.i.k. the first interpreter was written for the BASIC programming language in Dartmouth College in 1964.

When should you use it?

If you want the users of your application to be able to modify the behaviour of the application (scripting).
If the rules of your application need to be extended long after the application is finished.
If the Program may not directly access the Environment. The interpreter is a so called sandbox where the Program can play in without being able to do any harm.

How does it work?

One or more Programs or Scripts are loaded into the Interpreter. They may be converted into an internal representation that can be processed more effectively by the Interpreter. Connections between the Program and the Environment are created.

The Interpreter reads instructions from the Program and processes them. This affects the Environment. Changes in the Environment are fed back to the Program. This cycle is executed until the Program is finished.

Problems

Is slower than direct execution
Requires a custom made debugger
Requires the development and implementation of a feature-rich programming language

Common implementation techniques

The interpreter should not run in a separate thread from the environment, because it would create endless synchronisation issues. Emulate parallel processing in stead. Process only a few Program instructions every cycle.