[phylum]<3-LISP>documentation>old-3-interim-manual-02a.bravo!1

We take processes as our fundamental subject matter; though we will not define the concept precisely, we may assume that a process consists approximately of a connected or coherent set of events through time. The reification of processes as objects in their own right — composite and causally engendered — is a distinctive, although not distinguishing, mark of computer science. Processes are inherently temporal, but not otherwise physical: they do not have spatial extent, although they must have temporal extent. We will depict processes as rough-edged circles or balls, as in the following diagram. The icon is intended to signify what we will call the boundary or surface of the process, which is the interface between the process and the world in which it exists (we presume that in virtue of objectifying processes we carve them out of a world in which they can then be said to be embedded). Thus the set of events that collectively form a coherent process in a given world will all be events on the surface of this abstract object. In any given circumstance this set of events could presumably be more or less specifically described: we might simply say that the process had certain gross input/output behaviour ("input" and "output" would have to be defined as surface perturbations of a certain class: this is an interesting and non-trivial problem), or we might account in fine detail for every nuance of the process’s behaviour, including the exact temporal relationships between one event and the next, and so forth.

It is crucial to distinguish more and less fine-grained accounts of the surface of a process, on the one hand, from compositional accounts of its interior, on the other. That a process has an interior is again a striking assumption throughout computer science: the role of interpreters (what we will call processors) is a striking example. Suppose for instance that you interact with a so-called LISP-based editor. It is standard to assume that the LISP interpreter is an ingredient process within the process with which you interact: it in fact is the locus of anima or agency inside your editor process that supplies the temporal action in the editor. On the other hand that process never appears as the surface of the editor: no editor interaction is directly an interaction with the LISP processor. Rather, the LISP processor, in conjunction with some appropriate LISP program, together engender the behavioural surface with which you interact.

Every computational process (we will examine in a moment which processes we are disposed to call computational) has within it at least one other process: this supplies the animate agency of the overall constituted process. It is for this reason that we call this model a "process reduction" model of computation, since at each stage of computational reduction a given process is reduced in terms of constituent symbols and other processes. When there is but a single internal process, we call it a serial reduction, pictured in the following diagram (the arrow is intended to mean "reduces to"). In such cases the overall process is composed of what we will call a processor and a structural field. The first ingredient is the locus of active agency; the second is the program or data structures (or both).

To fill out the model just a little, we can suggest how we might, in these terms, define a variety of commonplace terms of art of computer science. First, by the computer science term interpreter (again, we use instead "processor") we refer to a process that is the interior process in a serial reduction of another interior process. Second, by a program we refer to a structural field arrangement within an interior processor — i.e., to the inner structural field of a double reduction — since programs are structures that are interpreted to yield processes that in turn interact with another structural field (the data structures) so as to engender a whole constituted behaviour. Third, by implementation we typically refer to two kinds of construction. To implement a process simply means to construct a structural field arrangement S for some processor P so that the surface of the process that results from the interpretation of S by P yields the desired behaviour. More interesting is to implement a language (by a computational language we mean an architecture of a structural field and a behaviourally specified processor that interprets arrangements of such a field). In its most general form, one implements a language by providing a process P that can be reduced to the structural field and interior processor of the language being implemented. In other words to implement LISP, all one is required to do is to provide a process that behaviourally appears to be a constituted process consisting of the LISP structural field and the interior LISP processor. Thus one is completely free of any actual commitment as to the reality, if any, of the implemented field. Typically, one language is implemented in another by: 1) constructing some arrangement or set of protocols on the data structures of the implementing language to encode the structural field of the implemented language, 2) by constructing a program in the implementing language that (when processed by the implementing language’s processor) will yield a process whose surface can be taken as a processor for the implemented language, with respect to that encoding of the implemented language’s structural field.

Thus the serial model can underwrite both language design and the construction of particular programs. For example, we can characterise FORTRAN in these terms: we will posit a FORTRAN processor that computes over (examines, manipulates, constructs, reacts to, and so forth) elements of the FORTRAN structural field, which includes primarily an ordered sequence of FORTRAN instructions, FORMAT statements, etc. Suppose that you set out to build a FORTRAN program to manage your financial affairs: what you would do is specify a set of FORTRAN data structures and a process to interact with them. We might call those data structures — the tables that list current balance, recent deposits, interest rate, and so on — the structural field of process CHEQUERS that you are building. The program that you want to interact with this data base we will simply call P. Thus the first reduction of CHEQUERS would be pictured in our model as follows:

There are three properties of all structural fields that are important to make clear. First, over every structural field there must be defined a locality metric or measure, since the interaction of a processor with a structural field is always constrained to be locally continuous. Informally, we can think of the processor looking at the structural field with a pencil-beam flashlight, able to see and react only to what is currently illuminated (more formally, the behaviour of the processor must always be a function only of its internal state plus the current single structural field element under investigation). For example, the well-known joke about a COME-FROM statement in FORTRAN is funny because it can be explained only because this local accessibility constraint is violated (otherwise it would be a perfectly well-defined construct).

Second structural field elements are taken to be significant — it is for this reason that we tend to call them symbols. We count as computational, in particular, only those processes consisting of ingredient structures and events to which we, as external observers, attribute semantical import. This attribution is neither something new, nor something specific to 3-LISP’s circumstances. The external attribution of significance is a foundational part of computer science.

The third constraint follows directly on the second: in spite of this semantical attribution, the interior processes of a computational process must interact with these structures and symbols and other processes in complete ignorance and disregard of any externally attributed semantical weight. This is the substance of the claim that computation is formal symbol manipulation — that computation has to do with the interaction with symbols solely in virtue of their shape or spelling. We within computer science are so used to this formality condition — this requirement that computation proceed syntactically — that we are liable to forget that it is a major claim, and are in danger of thinking that the simpler phrase "symbol manipulation" means formal symbol manipulation. But in spite of its familiarity, part of our semantical reconstruction will argue that we have not taken this attribution seriously enough.