[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue LOAD-TIME-EVAL, version 11
- To: alarson@src.honeywell.com (Aaron Larson)
- Subject: Re: issue LOAD-TIME-EVAL, version 11
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Mon, 20 Mar 89 09:03:45 MST
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
- In-reply-to: alarson@src.honeywell.com (Aaron Larson), Sun, 19 Mar 89 22:18:17 CST
> Date: Sun, 19 Mar 89 22:18:17 CST
> From: alarson@src.honeywell.com (Aaron Larson)
>
> My argument has been something like
> "The identity of the conses that make up a program shouldn't be significant
> to the value of the program". Proposal **3 sort of shoots down that
> argument.
The objection that was raised to proposal **2 was that the notion of
"references" to LOAD-TIME-VALUE forms was not well-defined. The one
example that was raised that bothered me the most was something like
(flet ((foo () (load-time-value (bar))))
(declare (inline foo))
(list (foo) (foo)))
Intuitively, there's only one reference to the LOAD-TIME-VALUE
expression, but if the compiler does the obvious transformation to
code FOO inline, you've suddenly got two references.
Basically, what proposal **3 does is avoid this whole problem by
putting the burden on programmers to be very careful about potential
sharing of LOAD-TIME-VALUE expressions. (It's really only a problem
for ones that are non-read-only.) There are some of us who feel kind
of uncomfortable about this, but it seemed like trying to come up with
a formal definition of what a unique reference to a LOAD-TIME-VALUE
form meant would open up an even bigger can of worms.
-Sandra
-------