Self-modifying code

[Henry Spencer]

In article <479 at m3.mfci.UUCP> colwell at mfci.UUCP (Robert Colwell) writes:
>But the whole point of capability machines (to name a single example)
>is that one cannot cover the space of all interesting
>exception-possibilities using only a compiler, no matter how smart.
>For one thing, the program could be coercing data types back and
>forth such that checking an operation on a type can only be done at
>the time the operation is applied.

Yes, it could be -- but how does the *programmer* know it's right?
Remember, programs are not supposed to dump core in production operation.
Remember also Dijkstra's comments on how human minds are actually fairly
simple and find it difficult to reason about complex situations.  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.

My conjecture, not proven at the moment, is that only modest intelligence
in the compiler and occasional tidying-up of code for clarity would be
needed to make case 3 fairly rare, given favorable cirumstances (it is
not clear that C constitutes a sufficiently favorable circumstance).

>But a more fundamental matter is how one manages the development of a
>large software project with dozens of programmers contributing to a
>single large end product.  The modules are all separately compiled,
>so there is no question of the compiler helping out much.

Please consider modern compiler technology, not 20-year-old versions.
Ways to achieve inter-module checking are a major concern in modern
languages, as witness (e.g.) C++ and Modula 2.  It can be done, and
ought to be done!

>Given access to all the symbol tables, you could imagine the linker
>doing some reasonable checks of consistency (number and types of
>args, for instance), but even that fails when pointers are being
>passed (pointers to functions, even).

If the assumptions being made about those pointers are simple ones, they
should be in the code, for compilers (and humans!) to see.  If they are
complex ones, then in a multi-programmer project they are probably being
violated already.
-- 
MSDOS is not dead, it just     |     Henry Spencer at U of Toronto Zoology
smells that way.               | uunet!mnetor!utzoo!henry henry at zoo.toronto.edu