Dennis E. Hamilton dennis.hamilton at acm.org
Sun Oct 8 18:27:48 EDT 2006

Generally, there are ways for a program to completely replace itself with a
new program so long as program replacement is permitted in the first place.

As a practical matter, especially with contemporary computers, there is some
kernel that is not replaced and is often recorded in storage that is
protected against alteration (such as the bootstrap loader that Eray Ozkural
mentions).  Even that may be altered by action of a program under special
conditions (e.g., a patch or update to the firmware of a typical modern

A challenge for the kind of alteration being discussed here is the need to
make a new persistent version on a recorded medium (such as a hard drive).
That's so the next time the computer is started up, the new form of the
program is used.  This kind of business may be interfered with by security
arrangements of contemporary machines, where the installation of new code is
monitored to defend against introduction of malicious code as well as code
intended to overcome  other protections of the system.

I don't think these are material barriers in the context of the discussion
on FOM.  Even with the program confined to operation in some sort of
security sandbox, it should be feasible to have program codes that can
replace themselves and are able to store themselves for future use.  There
are many ways to do that.  

I think the greater challenge is not having a program that can replace
itself, but having the system be operating successfully and usefully while
that is happening.  A common desire is to have there be no interruption in
operation that matters to users/operators of the system.   The IBM
Corporation (with its autonomic computing initiative) and other companies
are looking at systems that are adaptive in just that way as part of
overcoming software as well as hardware failures.  There is generally an
additional safeguard involving the ability to revert to an earlier version
when, by some happenstance, the new form of the program or the switchover to
it fails.

It is not necessary to replace all software on the computer to challenge (or
affirm) theses about software that consults its own description in some way.
One can easily consider a program that is designed to accomplish this with
regard to itself and not be fussy about anything else that the host computer
system is organized for.  Even if the program is required to incorporate a
universal computation function, that does not have to involve alteration of
the host (so long as it has a universal computation function or a
close-enough practical equivalent which can be relied upon to implement the
one in the program of interest).  I'm confident that John McCarthy knows of
examples where this kind of thing has been done within/on Lisp systems for
various purposes.  

I suggest it is therefore safe to move on the heart of the question,
considering what it would take for a computer program to possess a
description of itself that it can consult in deriving/constructing itself or
an improvement thereto, along with a suitably-updated description that its
offspring can use in the same way.  This sounds a bit like von Neumann's
notion of self-reproducing systems.  I'm not sure we know what such a
description would be like and the kind of deductions that the program would
be required to carry through.

It seems to me that one activity we would not be interested in performing
with such a program is having it find defects in its own description or
proving its own unsoundness, whatever that could possibly mean.  If we had
the means to do that, we would do it before we put that program into
operation, using a different program to do the checking.  (I leave the
apparent regress here to be pondered over.)

 - Dennis

Dennis E. Hamilton
The Miser Project / Numbering Peano / Orcmid's Lair
mailto:Dennis.Hamilton at acm.org | gsm:+1-206.779.9430 
http://miser-theory.info/astraendo/pn http://orcmid.com/blog

-----Original Message-----
From: fom-bounces at cs.nyu.edu [mailto:fom-bounces at cs.nyu.edu] On Behalf Of
laureano luna
Sent: Sunday, October 08, 2006 00:54
To: fom at cs.nyu.edu

Eray Ozkural wrote (about some computer):

> 2) It can keep a full trace of execution and then change/debug its 
> programming.

I'm no expert, but it seems to me that to avoid circularity the fact has to
be that a part of a program changes another part of that program. So, a
question: won't there always be an unchanged core in the programming of
every possible computer?


Laureano Luna Cabañero

[ ... ]

More information about the FOM mailing list