Self-modifying code

[Hank Dietz]

In article <12360 at ut-sally.UUCP>, nather at ut-sally.UUCP (Ed Nather) writes:
> In article <33441 at yale-celray.yale.UUCP>, lisper-bjorn at CS.YALE.EDU (Bjorn Lisper) writes:
> > 
> > I guess there are situations with extreme performance requirements where
> > self-modifying code is justified. It would be interesting to see what a
> > semantics for self-modifying programs would look like. 
> 
> I agree.  That was the whole point of my original posting -- to see if someone
> with a talent for languages could ignore the current prejudice against this
> practice, and see what might be done.  If there's really no way to do it in a
> reasonable manner, fine -- but just *saying* it's awful doesn't *make* it awful.

The key problem with self-modifying code is that code created at runtime may
REPLACE code that appeared at "compile" time, hence, in general, no STATIC
understanding of the code is possible.  This can make it hard for humans to
understand the code, but more importantly it implies that compilers cannot
perform optimizations, e.g., you cannot perform register allocation / value
propagation / common subexpression elimination / in-line expansion because
the code you remove might be code which is modified at runtime.

The fix need not be the elimination of the generate-and-execute programming
concept, rather, the language merely needs to specify constraints on the code
which is to be generated at runtime.  For example, key constraints would be
that the runtime generated code could not redefine any existing function,
could only be invoked through a statically-specified interface, and could only
access data which either was statically-declared as accessible through that
interface or was created as new data local to the new code.  In other words,
we can permit code to add to itself, but not to redefine what existed at
compile time:  self-extending code.

An outline of fixes to be applied to Lisp (to create "Refined Lisp") appears
in my PhD thesis:  H. Dietz, "The Refined-Language Approach to Compiling for
Parallel Supercomputers," June 1987.  The folks working on Scheme had similar
ideas....

						-hankd