[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: uses of #,
- To: CL-COMPILER@sail.stanford.edu
- Subject: re: uses of #,
- From: goldman@vaxa.isi.edu
- Date: Tue, 21 Jun 88 09:32:41 PDT
- Posted-date: Tue, 21 Jun 88 09:32:41 PDT
- Sender: goldman@vaxa.isi.edu
I believe that all our uses of #, would be subsumed by the following
construct, which we have implemented in various ways in each of 3
common lisp implementations, but believe cannot be implemented portably
within common lisp as it now stands:
UNVARYING e [Special Form]
e may be any expression. The value of (UNVARYING e) is simply the (first)
value returned by e. However, the programmer authorizes the implementation
to cache the value and return the cached result (or a value EQL to it) on
successive executions of the same occurrence of (UNVARYING e).
There is NO implication that the value may be computed at "compile" time,
although analysis of e may show that it is safe to do so under some
circumstances -- in particular, if e involves only constant subexpressions
and contstant, side-effect-free, stateless, functions and macros.
One implementation we have expands (UNVARYING e) into:
(let ((#:G0001 '(NIL . NIL)))
(if (car #:G0001)
(cdr #:G0001)
(setf (car #:G0001) t (cdr #:G0001) e)))
[This implementation will not work, of course, on an implementation that
takes the position that a quoted CONS datum may not be smashed.]
We use this macro in many places where "#," cannot be used, because it
appears in the expansion of some other macro. I believe that all the uses
we make of the "read-time" evaluating done by "#," could be replaced
acceptably by the "first execution time" evaluting done by UNVARYING.
On the other hand, most of our uses of UNVARYING COULD
be safely evaluated at "load" time, and would yield somewhat smoother
performance if evaluation were done then rather than at first execution
time. So I'd like UNVARYING to have an optional parameter to specify
whether load-time evaluation is authorized, with the default being YES.
[Of course, this assumes that the concept of "load time", or "program
construction time", is considered to be sufficiently well defined that
language semantics can refer to it.]
The reason that compile-time evaluation won't work in most of these cases
is that it is not proper to "create" (i.e., cons) the VALUE at
load time, only to "find" it. The expression e constitutes the
directions for finding the correct value.