Issue: DYNAMIC-EXTENT (Version 3)

[Jon L White <jonl@lucid.com>]

re:  However, it still raises the question of whether we should define
     per-function for every CL function whether any of the arguments is
     permitted to be "saved" so that CL programs don't get any funny surprises.
     If we don't, it ends up being implementor's discretion how to resolve
     cases like this, and everyone might not agree that all cases are as 
     obvious as this one was.

PDP10 MacLisp had a similar problem w.r.t pdlnums.  That is why
"identity" functions were so troublsome for it -- in order to
return a guaranteed safe value, it typically had to copy it's
pdlnum argument, thereby making some cases of "fast arithmetic" 
code much worse than interpreted code!  [Remember PRINT in MacLisp?
it returns T rather than it's argument for just this reason.]

It is necessary for an optimizing compiler to know something about
what happens to the data it passes along to "system" functions; for
example, it could assume that GET doesn't clobber the list given
to it, nor does it retain pointers to any part of it [what was the
terminology in the revised proposal?  "saved"? and "proper part"?]
The issue LISP-SYMBOL-REDEFINITION might help here, in that an
implementation's compilers could depend upon it's own internal
database.  But it wouldn't hurt at all to have some of these
requirements "up front" in the standard.


-- JonL --