Structure sharing in arguments

[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)


About an earlier issue which I didn't have time to respond to when
it came up regarding the error level proposal:  regardless of how the details
are worked out, I don't want the set of "must" reportable errors to be very
large.  At least not at all levels of safety/speed.  There should be an out
of at least one combination which allows very minimal error checking.  If I
remember correctly from your proposal, you suggested that anything which
"signals an error" should be an always required reportable error.  I wouldn't
mind having only one combination of safety/speed which would not require this,
but I would strongly object to having all these errors required to be
reportable no matter what optimizations are requested.  Conventional
architecture implementations pay a substantial performance penalty for every
error check emitted in the final code.

	John