"Lisp process" -> "Lisp image"

Following the HyperSpec's glossary.

Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>

4 files changed, 9 insertions, 9 deletions

diff --git a/doc/data.rst b/doc/data.rst
index 7780ae7..d30eab8 100644
--- a/doc/data.rst
+++ b/doc/data.rst
@@ -37,7 +37,7 @@ the ``DATA-UPLOADED`` property, to get access to the requested data.
 
 A Lisp connection gathers all needed prerequisite data once at the beginning,
 and copies it to an on-disk cache inside the home directory of the remote UID
-which will run the Lisp process.  A POSIX connection only attempts to obtain
+which will run the Lisp image.  A POSIX connection only attempts to obtain
 prerequisite data when a property's check function indicates the property is
 not already applied.
 
diff --git a/doc/introduction.rst b/doc/introduction.rst
index f35f441..65cedea 100644
--- a/doc/introduction.rst
+++ b/doc/introduction.rst
@@ -29,7 +29,7 @@ Connection
 A means by which properties can be applied to hosts, and multihop connections
 to other hosts can be established.  There are two types of connections: those
 which interact with the remote host by means of a POSIX shell, and those which
-apply properties by executing them in a Lisp process running on the host.
+apply properties by executing them in a Lisp image running on the host.
 
 POSIX connections can pass input to and return output from processes, but
 cannot start asynchronous processes for interaction with your Lisp functions.
@@ -52,7 +52,7 @@ be nested: one remote host can be used to deploy others, as a controller.
 Root Lisp
 ~~~~~~~~~
 
-The Lisp process you control directly when you execute deployments.  Typically
+The Lisp image you control directly when you execute deployments.  Typically
 running on your development laptop/workstation (and not as the ``root`` user).
 
 Property application specification
@@ -100,7 +100,7 @@ data; this avoids uploading the same data over and over again.
 In addition to secrets management, prerequisite data is Consfigurator's
 mechanism for the common need to upload files to controlled hosts.  The same
 mechanism is used internally to upload the Lisp code needed to start up remote
-Lisp processes for ``:lisp`` connections.
+Lisp images for ``:lisp`` connections.
 
 Consfig
 ~~~~~~~
diff --git a/doc/pitfalls.rst b/doc/pitfalls.rst
index d4bcb4a..7a7bbae 100644
--- a/doc/pitfalls.rst
+++ b/doc/pitfalls.rst
@@ -27,7 +27,7 @@ not try to define properties and connection types programmatically, or try to
 dynamically rebind or flet-bind them.
 
 The reason for this restriction is that some connection types need to invoke
-fresh Lisp processes on remote hosts with (local equivalents to) the function
+fresh Lisp images on remote hosts with (local equivalents to) the function
 objects contained in properties and connections available to be called.  Since
 function objects are not serialisable, the only way to do this is to send over
 the contents of your ``.lisp`` files and load the same properties and
@@ -35,8 +35,8 @@ connection types into the remote Lisp.  By contrast, hosts, property
 application specifications and deployments can be send over in serialised form.
 
 If you were to dynamically rebind properties or connection types in the root
-Lisp, then connections which do not start remote Lisp processes would use your
-new definitions, but connections which start remote Lisp processes would use
+Lisp, then connections which do not start remote Lisp images would use your
+new definitions, but connections which start remote Lisp images would use
 the static definitions in your ``.lisp`` files (or lack definitions
 altogether).  This would violate the idea in Consfigurator that properties,
 including nested deployments, have the same meaning regardless of the
diff --git a/doc/properties.rst b/doc/properties.rst
index 9261127..6df06ff 100644
--- a/doc/properties.rst
+++ b/doc/properties.rst
@@ -58,12 +58,12 @@ Errors in attempting to apply a property are indicated by signalling a
 
 ``:posix`` properties should not make any assumptions about what localhost is
 -- they may be running in the root Lisp, but they might be running in a Lisp
-process running on an intermediary host, or even on the host to be configured.
+image running on an intermediary host, or even on the host to be configured.
 They should perform I/O only by calling ``RUN``, ``RUNLINES``, ``READFILE``,
 ``WRITEFILE``, requesting prerequisite data, and applying or unapplying other
 ``:posix`` properties.  Otherwise, they should be pure functions.
 
 ``:lisp`` properties, by contrast, may (and should) assume that they are
-running in a Lisp process on the host to which they are to be applied, so they
+running in a Lisp image on the host to which they are to be applied, so they
 can perform arbitrary I/O in that context.  They can also make use of ``RUN``,
 ``RUNLINES``, ``READFILE`` and ``WRITEFILE`` if desired.