Structure sharing in arguments

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

    Date: Tue, 22 Jul 86 21:39:37 pdt
    From: hpfclp!diamant@hplabs.HP.COM

	    From: Scott Fahlman <fahlman@C.CS.CMU.EDU>
	    Subject: Some easy ones (?)
	    Proposal #13: Structure Sharing in Arguments
	
	    Clarification:
	
	    Specify that the &REST or &BODY argument to a macro may be the very list
	    from the macro call, and not a copy, and therefore the user should not
	    perform destructive operations on it.
	
	    Similarly, a function that takes a &REST argument should not
	    destructively modify it because in some implementations its top-level
	    list structure might share with a list that the user gave as the last
	    argument to APPLY.

    I don't really care whether you add a restriction not to do destructive
    operations on a &REST or &BODY argument, but it better be clear that the
    list returned may not be something which will go away on exiting the function
    (which could happen if the parameter list were stored on the stack and a
    pointer to that list was returned -- apparently what Symbolics does).
    Nothing currently in CLtL limits me from doing the following (nor should it):

    (defun foo (&rest x) x)

(defun list (&rest list) list)
(defun copy-list (list) (apply #'list list))

[Yes, Symbolics uses stack-consed &rest lists, and they will screw you
every now and then.  >>> My view of our current position <<< is that the
efficiency issues (e.g., not calling copy-list on every &rest arg) are
outweighed by the programmer resources needed to implement the copying
only when necessary.]

I'm fairly convinced that disallowing destructive operations on &rest
lists is funtionally equivalent to not being allowed to store them in
stable storage or to return them.  I think my first proof caused CLtL to
dictate some aspects of function calls.  I'm looking for a proof that is
within the bounds of CLtL that does have such dictations.  Maybe there
aren't any.  Maybe I'm wrong and they aren't equivalent, but I suspect
they are.