[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: issue LOAD-TIME-EVAL
- From: email@example.com (Sandra J Loosemore)
- Date: Fri, 12 Aug 88 08:55:08 MDT
- Cc: firstname.lastname@example.org
Here are some of my thoughts on cleaning up the existing proposal for
LOAD-TIME-EVAL:NEW-SPECIAL-FORM. I haven't yet heard anybody
objecting to discarding the QUOTED-MAGIC-TOKEN proposal on the same
issue -- speak now or forever hold your peace!
LOAD-TIME-CONSTANT form &optional read-only-p [Special Form]
All processing of the FORM is deferred until the expression is
in the "runtime" environment. Once that environment is available,
FORM is evaluated in the null lexical environment and the result
is both returned and saved for immediate access by the program
on subsequent evaluations.
In the interpreter, the FORM may be evaluated during pre-processing
(if any) or dynamically when the LOAD-TIME-CONSTANT is first seen
(in a non-pre-processing implementation). If the same LOAD-TIME-CONSTANT
expression is later seen again by the interpreter, the previously
obtained result is immediately retrieved and returned as the result
of evaluating the object; no re-evaluation occurs.
There is some possible confusion over what "the same LOAD-TIME-CONSTANT
expression" means; in particular, is it the entire LOAD-TIME-CONSTANT
form or the evaluable form inside of it that is compared? What predicate
is used to compare them -- EQ or EQUAL? And, is it the *reference* to
the LOAD-TIME-CONSTANT form that is checked, or the form itself --
something which makes a big difference given that there may be multiple
references to the same code fragment? In other words, is it a legitimate
implementation technique for the interpreter to destructively bash the
list (LOAD-TIME-EVAL <foo>) into (QUOTE <what-foo-evaluates-to>)?
If the LOAD-TIME-CONSTANT expression is seen by the file compiler
(eg, COMPILE-FILE), the compiler arranges for all semantic processing
of FORM (including macro expansion) to occur at load time in a null
lexical environment (independent of whether any value has been cached
for interpreter use). At runtime, the result of that evaluation will
be treated as an immediate quantity; no re-evaluation occurs.
Doing macro expansion in a null lexical environment makes this behave
more like (EVAL-WHEN (COMPILE) ...) than (EVAL-WHEN (LOAD) ...).
If a LOAD-TIME-CONSTANT expression is seen by the runtime compiler
(eg, COMPILE), the compiler checks for a cached value which may have
been produced by the interpreter. If one is found, it is used. If no
such value is found, the runtime compiler will evaluate the FORM in
a null lexical environment and use that value. The value used will be
treated as an immediate quantity in the code which is produced; no
Is the compiler supposed to cache the value of FORM for later use by
the interpreter? Again, this is a concern if there are multiple
references to the same expression.