Issue: REST-LIST-ALLOCATION (Version 3)

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

This is a tough issue.

NEWLY-ALLOCATED and MUST-SHARE have the virtue of involving the fewest
hassles for portable code. Latent surprises of this kind are invariably
terribly hard to track down, and it's a definite feature to avoid the
problem.

On the other hand, MAY-SHARE is the clearly efficient thing for what is
probably the most common case, so we should be careful not to pick a
semantics that forces undue expense in that case.

This problem may be related to the DYNAMIC-EXTENT issue. Just as we want
the option of new structures being stack-allocated, we seem to want the
option of new structures being shared or unshared. I could imagine,
as GZ suggests, a declaration to accomodate this. For example:
 (DEFUN FOO (&REST X)
   (DECLARE (UNSHARED-STRUCTURE X))
   ...)
We might someday figure a way to generalize to other cases, such as uses
of backquote. Consider:
 (LET ((X `(A ,B C)))
   (DECLARE (UNSHARED-STRUCTURE X))
   ...)
For now, though, I think it best to consider restricting the variable to
only &REST variables (by not allowing the variable to be specified!).
This kind of declaration may sound bizarre, but I think GZ is right in
asserting that it's an important thing that portable programs must 
constantly reckon with and need a serious solution for.

On the basis of the reasoning presented above, my position is that we
should do the following two things:

 - Drop the NEWLY-ALLOCATED and MUST-SHARE variants as practically
   infeasible and ramp up MAY-SHARE.

 - Extend MAY-SHARE to include a mechanism that seriously addresses
   the fact that sometimes we need to get a particular kind of
   functionality. Perhaps declarations like
     (REST-LIST-SHARING :NEVER)
     (REST-LIST-SHARING :SOMETIMES)     
     (REST-LIST-SHARING :ALWAYS)
   or
     (REST-LIST-ALLOCATION :NEW)
     (REST-LIST-ALLOCATION :UNSPECIFIC)
     (REST-LIST-ALLOCATION :SHARE)
   The only issue then would be whether there were implementations where
   the always-share functionality would be impossible to implement (since
   the never-share functionality could at least be simulated in 
   implementations where it couldn't be reliably detected), and whether we
   were willing to allow such implementations to just signal an error in
   that case. (If we were to permit implementations to not implement :SHARE,
   we might be better off not offering the feature in the first place.)