Self-modifying code

[Mike Coffin]

>From article <1988Jul29.202400.28068 at utzoo.uucp>, by henry at utzoo.uucp (Henry Spencer):
> ...  There are three possibilities here:
> 
> 1. Code is simple enough for human programmer to figure out easily, in
> 	which case the compiler should be able to do likewise, perhaps
> 	with a bit of help.
> 
> 2. Code is wrong, human programmer is (e.g.) not validating his inputs
> 	properly.  Compiler should reject it.
> 
> 3. The code really is right but very subtle.  Programmer has to have a
> 	way to tell the compiler "this is subtle but right".  This should
> 	not be the default, as it effectively is now.

4. Code is simple enough for a human programmer to figure out easily
given "deep" knowledge about what the program is doing, in which case
a compiler has big troubles figuring out almost anything.  I have
worked on some mathematical software --- computational group theory,
if it matters --- where the code itself looks broken unless you know
the right theorem.  The theorem establishes an invariant that makes
the code very easy to understand.

I just thought of a simple example: a piece of code relies on the fact
that an array always contains a permutation of the integers 1:N.  This
invariant is originally established by generating a random permutation
via a very clever algorithm (Floyd's), and then maintained by always
permuting the integers --- sometimes swapping them, other times
rotating several.  A procedure that relies on the fact that the array
is a permutation is going to be extremely opaque to the compiler, yet
might be transparent to a programmer.  (Especially if the array is
called "permutation".)

-- 

Mike Coffin				mike at arizona.edu
Univ. of Ariz. Dept. of Comp. Sci.	{allegra,cmcl2,ihnp4}!arizona!mike
Tucson, AZ  85721			(602)621-4252