A behavioural characterization of computational

systems
Javier Blanco

Renato Cherini
Po Garca

Martin Diller

Universidad Nacional de C
ordoba, Argentina
e-mail: blanco@famaf.unc.edu.ar

Abstract
We introduce the concept of interpreter as a producer of behaviours in
response to some inputs that codifies them. We argue that the notion of
interpreter captures the minimal characteristics shared by different kinds
of computational devices, and can thus serve as a criteria to identify how
interesting a computational system is. This characterization contrasts
with many of the current functional descriptions offered in the literature
on this topic, in that these are somewhat dependent on the technology
that is currently available. Since the concept of interpreter can be used
to compare different systems, it defines a computational hierarchy, establishing the relative degree of computationalism of different systems. This
enables us to restate some ontological questions, such as what is a program?, when is a system computational?, in more precise terms which
admit clearer answers.

Any system can be characterized in terms of its possible behaviours. In

particular, a useful description of a computational system is given by the relationship between the input and the behaviour produced as a response to that
input, characteristic of the system. The feature that distinguishes computational systems from other types of systems is that they may produce a very large
and interesting set of behaviours, depending on syntactic inputs and without
changing a single wire [Dij88]. Thus, the characteristic input-behaviour relation implicitly defines an encoding of behaviours as syntactic objects.
We have suggested in [BCDG11] that some key aspects of computational
systems can be captured by the ubiquitous concept of interpreter as used both
in theoretical and applied computer science [Jon97, AS96, HH98], defined in a
very general manner. In this article, we present an interpreter as the necessary
link between a set of behaviours and their respective encodings, without relying
on any mechanistic account of systems. As we argue elsewhere, the concept
of interpreter can be regarded not only as a notion that captures the minimal
common characteristics of different types of computational devices which clarify
various concepts which pervade computer science, but also as a framework for
understanding computing.
By behaviour of a system we understand only a description of the occurrences
of certain events considered relevant of the system. Different ways of observing
a system may determine different sets of behaviours. Thus, the behaviours will
depend on a decision regarding the events that are considered of interest for that
1

system (for particular purposes). A precise definition of behaviour will be left

unspecified here, since this will only make sense when a particular framework is
stated.
Intuitively, an interpreter produces a behaviour according to some input that
codifies it. Usually, the encoded behaviour may depend on input data, but for
simplicity we will assume in this presentation that the data and behaviour are
already encoded together. The notion of interpreter is (almost) by definition the
necessary link between the so-called program-scripts and program-processes
[Ede07, BG08].
Given a characterization of a fixed set B of possible behaviours, and a set
of syntactic elements P , an interpreter is a function i : P B assigning some
behaviour b B to every p P . When this relation is given, we say that
p is the encoding of b. Generally, we speak of the syntactic domain P as the
programming language, and of p as a program.
A (physical) system I realizes an interpreter i if it is capable of receiving
an input p, and systematically produce the observable behaviour b such that
i(p) = b. In this case we say that I effectively computes b via the program
p. We say that a (physical) system realizes an interpreter when every time
we provide it with an instance of an encoding, it produces the corresponding
observable behaviour. We do not consider internal states, since these may be
realized in very different ways.
One way of precising the notion of realization is along the lines of the notion
of practical realization of a function defined in [Sch99], where the relation is
an isomorphism between the formal definition of i and a physical theory T that
describes the system I (for example, the theory of electrical circuits) that includes a description of the inputs and outputs of the system as well as a function
F that maps inputs to outputs using the laws and language of T in a way that
guarantees the preservation of the ismorphism. In [Sch99] different degrees of
practicality of the realization relation are also considered that take in account
the limits in precision with which the inputs can be measured and generated,
reliability and range of functioning of physical systems, noise generated by the
environment, etc.
The concept of interpreter serves as a criteria to distinguish between systems
that could be computational (w.r.t some inputs and behaviours) from those that
could not. Since we want to capture what makes any system programmable, we
do not assume any particular implementation technology in the concept of interpreter. Different computational models, like Von Neumann machines, parallel
machines, DNA-computers, quantum-computers, can be considered interpreters
because they can systematically produce behaviours from their encodings in a
predefined language. What will be specific to each model is the underlying theory used to justify that they are interpreters, not the criteria used to determine
that they are indeed programmable systems.
The notion of interpreter can be seen as functional, i.e, an interpreter is such
when it is capable of producing behaviours from programs. Following this idea,
a program is a syntactic structure capable of being interpreted. A program
is such only relative to a given interpreter and an interpreter is such only for
a particular programming language. The concepts of program, programming
language and interpreter are thus relational and inter-definable.
The main feature of an interpreter is that it is programmable: there is an
available syntax with which a variety of behaviours can be encoded. The degree
2

of programability of an interpreter is given by the variety of behaviours that the

underlying programming language is able to encode. The degree of programability is the distinctive feature of an interesting computational system. If we
consider a system computational when it is programmable, then being computational will also be a property which can be established only relative to a set of
behaviours and a corresponding encoding (usually an actual programming language). In other words, the property of being computational will not make sense
independently from a set of behaviours and the encoding. This will allow us to
tackle some philosophical problem such as the problem of pan-computationalism
(do all physical systems compute?) [Put87, Sea04, Cha96, Chr94, Cop96, Pic08]
from a different perspective. The question Is this a computational system? is
replaced by the question Is this a computational system with respect to this
set of inputs and behaviours?, or equivalently, How interesting, from a computational point of view, is this system?. From this perspective, in particular,
several constructions of trivial implementations of programs which intend to
show how the thesis of pan-computationalism can be established, do not qualify
as interesting computational system.
Since the rise of computability theory in the thirties, it was clear that a
computation is related to certain formal object that prescribes it, e.g. the
description of a Turing Machine, general recursive functions, a lambda-term,
etc. A computation, then, is produced following this prescription. Putnams
(and Searles) theorem [Put87, Sea04], on the other hand, tries to present a
notion of computation in itself, reifying computation as something that exists
independently of the prescription or program (any sequence of states would do).
The property of being an interpreter for a given set of behaviours can be
satisfied by certain systems. An interpreter is a general notion that can be used
to characterize physical mechanisms (computers, calculators), a human acting
mechanically (Turings computor, a human carrying out the reductions of a
lambda term), mathematical formalisms (universal Turing machines, etc.), or
computers with computing power beyond Turing computability (Oracle computers [Cop02]). Whereas a (physical) counterpart is needed for the realization
of an interpreter, the property of being an interpreter, and concomitantly, the
property of being a programmable system, can be determined by its abstract
description.

References
[AS96]

Harold Abelson and Gerald J. Sussman. Structure and Interpretation

of Computer Programs. MIT Press, Cambridge, MA, USA, 2nd
edition, 1996.

[BCDG11] Javier Blanco, Renato Cherini, Martin Diller, and Pio Garca. Interpreters: towards a philosophical account of computer science. Technical Report, 2011.
[BG08]

Javier Blanco and Pio Garcia. A categorial mistake in the formal

verification debate. In European Conference on Computing and Philosophy (ECAP), June 2008.

[Cha96]

D. Chalmers. Does a rock implement every finite-state automaton,

1996.

[Chr94]

Ronald L. Chrisley. Why everything doesnt realize every computation. Minds and Machines, 4(4):40320, 1994.

[Cop96]

B. Jack Copeland. What is computation? Synthese, 108(3):33559,

1996.

[Cop02]

Jack Copeland. Narrow versus wide mechanism. In Computationalism: New Directions. MIT Press, 2002.

[Dij88]

Edsger W. Dijkstra. On the cruelty of really teaching computing

science. circulated privately, December 1988.

[Ede07]

Amnon H. Eden. Three paradigms of computer science. Minds

Mach., 17(2):135167, 2007.

[HH98]

Jifeng He and C. A. R. Hoare. Unifying theories of programming. In

Ewa Orlowska and Andrzej Szalas, editors, RelMiCS, pages 9799,
1998.

[Jon97]

Neil D. Jones. Computability and complexity: from a programming

perspective. MIT Press, Cambridge, MA, USA, 1997.

[Pic08]

Gualtiero Piccinini. Computers. Pacific Philosophical Quarterly,

89(1):3273, 2008.

[Put87]

Hilary Putnam. Representation and Reality. MIT Press, 1987.

[Sch99]

Matthias Scheutz. When physical systems realize functions. Minds

and Machines, 9(2):161196, 1999.

[Sea04]

John Searle. Is the brain a digital computer?, 2004.