Function constants

[Richard P. Gabriel <rpg@lucid.com>]

well, it seems that there is a straightforward way to correspond EVAL
and COMPILE-FILE, which I didn't think was necessary to explicate, but
now I will:

Let S = F1,...,Fn be a series of forms. We ignore well-formedness for
the moment, as well as representation, which I will return to.

Let C = {F1,...,Fn}, a compilation unit with those forms in that
order.  Let C' be C compiled with compile-file. A fresh Common Lisp
(CLf) when EVALing each element of S in that order should result in
the ``same observable behavior'' that you get by LOADing C' into a
fresh Common Lisp.  Observable behavior includes most everything you
can think of except the representation of the functional (and macral)
objects created and the storage allocation/reclamation behavior.

Presumably each Fi is a textual representation of a form.  You can
probably approximate this with LOAD for the EVAL case, but I don't
want to exclude typing them in. Unfortunately, we are in a position to
talk only about LOADing a compiled file rather than having some clear
READ-EVAL-PRINT model for compiled objects.

Now, there is clearly some limitation on what the structure of S (or
C) and each Fi can be in order to achieve the ``same behavior,'' and
we probably need to define observable behavior.

An interesting point is the EQness relationship among objects referred
to in S. In all cases, this EQness refers to the EQness of the objects
in CLf, not in any other Common Lisp that might have been involved in
the creation of S, C, or C'. These relationships ought to be derivable
from examination of the text in S. To achieve the same observable
behavior, we might need to consider equivalence classes of behavior
that is defined by those equivalence relations specified by unspecified
behavior. (That is, if our specification of Common Lisp states that
two things may or may not be EQ in some situation, this defines an
equivalence of behavior.)

Part of the same observable behavior is the observed semantics of
programs that run as a result of EVALing the expressions or LOADing
the compiled code. Again, this is up to equivalence classes.

All I'm wondering is how obnoxious the structuring rules and
equivalence relations must be to make this statement of same behavior.
Thus, I am indeed talking about how to structure files for Common Lisp
programs so that the semantics of those programs is the same whether
or not anything like a compiler has seen them.

			-rpg-