[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: constant folding/smashing
Date: 1 Jun 1988 15:36-EDT
I believe there are 3 places in CLtL where "constant objects",
"constant values", and "constants in code" are discussed:
DEFCONSTANT pgs. 68-69
EQ pg. 78
QUOTE pg. 86
I think we have to be very careful about the semantics of constants and
variables. For example, does DEFUN proclaim the functional value of a symbol
is a constant? What about (compile 'mumble ...)?
I think we must break these constants down into an ontology, and consider
each class separately. Variables and Parameters (e.g. from DEFVAR and
DEFPARAMETER) are obviously different: Variables are things that may change
their values many times during a particular execution, while Parameters are
constant during a particular execution. This semantics extends into
variables and parameters vis. function calls as well, so we need not limit
ourselves to talking about program invocations.
But there seem to be some other things as well, though CL (or necessarily
any other language) break them out.
An Unknown might be defined as an object that changes at most once during a
particular execution. (A single assignment variable). Prolog variables are a
good example. (I don't necessarily think they should be in common lisp,
though they are rather hard to add given there is no way to make new
A Functional constant may be one that rarely changes between executions of
a funcion/program and never during execution. THe usual use of DEFUN covers
this: if you blow into the debugger and redefine a function, you don't
expect invocations of the function below you on the stack to be updated with
the new definition. Note that functions that are redefined during execution
are considered variables under this ontology.
A Declared constant (e.g. objects created by DEFCONSTANT) is one that Never
changes in a particular implementation. The compiler is allowed to fold
these things safely, since the user will not be expected to incrementally
patch them, without recompiling the entire system. Macros, (unfortunately in
some sense,) currently have this semantics.
A Defined constant is something that never changes BETWEEN implementations.
I.e. the value of PI, or other things some STANDARD defines. I separate this
from declared constant, because when one reads the symbol PI or E or
whatever, one beleives the reference is to this well known object (though
the implementation may have an imperfect description) rather than to some
constant the programmer has happened to name that.
I suppose if one wanted to wax ontological, one could separate two kinds of
defined constants: those that have a value as a matter of logical necessity,
i.e. their value is part of their definitions (e.g. PI) and those that
simply are not known to have changed in human experience, so we can assume
they are constant for all practical purposes (an empirical constant, like
the speed of light in a vacuum)
Now for each of these types (and a finer ontology than this may certainly be
necessary) there are the issues of when it is safe or unsafe for the
compiler to fold, and when it is just a good or a bad idea for the compiler
to fold, based on the information that will be preserved for the debugger,
allowing incremental redefinition, etc.
Now the question becomes, what sort of object is 'A? A declared constant, a
functional constant, or even a parameter? I infer that some people want to
treat it as a functional constant, which would make folding undesirable (at
least), and others a declared constant where folding would be desireable (or
at least safe and logical).
We also have to be careful in that the properties of an object may, indeed
must be treated separately. A's functional value my be a functional
constant, but it's symbol-value may be a variable or parameter. The same can
be said of any other properties of the object, except for it's printname,
which would seem to be a defined constant (the object that I write as A has
a printname of "A" is the way these sorts of atoms are defined by the
Brad Miller U. Rochester Comp Sci Dept.