Issue: DYNAMIC-EXTENT (Version 3)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Even though this is very different (more permissive) than what I'd first
written up, I have to say I really like this rewrite a lot. It's quite
clever in the way it presents things in order to get additional flexibility.

However, I do have a few comments I'd like to see addressed before this
gets to a vote...

 * I like the concept "proper part" a lot but I don't like the name.
   The term "proper" for proper lists has to do with well-formed-ness
   and in this context you're suggesting an incompatible meaning which
   is confusing.
   
   I suggest instead a term like "internal", "intrinsic", "private",
   "unshared", etc.
   
   [The concept of "unshared" makes me immediately scared about the
    whole quote-may-copy morass, but I don't have time to think through
    right now whether that's an issue that needs further clarification
    or if it's just a red herring.]

 * I like the concept of "saved" but it has the problem that it isn't
   easy to bring up "out of context" since "save" has a lot of connotations.
   If it were possible to come up with a more unique term, I think it
   would help in lunch table conversations when people start getting
   screwed by things that were `unintentionally saved' and others can't
   figure out what they mean out of context.

 * I think your list of definitions for saved is pretty good, but I'd
   still like to see an abstract definition, and then the concrete cases
   listed beneath it. That way, we are protected from weird unintentional 
   interpretations if someone discovers that the set was not exhaustive
   and needs to include their new case under the abstract description
   because the concrete list doesn't accomodate things.

 * What about things like:

   (DEFUN FOO (&REST X)
     (DECLARE (DYNAMIC-EXTENT X))
     (MAPL #'PRINT X)
     T)

   Genera's Dynamic Windows (DW) had bugs in its first release because the
   window history recorded the object which was printed. Put another 
   way, PRINT did unexpected "saving" on some streams. The situation with
   DW was treated as a bug and now DW correctly detects stack-allocated
   things and does not try to save them, so this would work now.
   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.