Re: #13, #14

[Andy Latto <alatto@cc5.bbn.com>]

Proposal #13: Structure Sharing in Arguments

	Kent says:

...
    For a function that takes &REST arguments, I would prefer that a copy
    always be made unless the interpreter or compiler can prove that it 
    won't be necessary. If we cannot agree to do that, then it must be 
    noted both that it "is an error" to modify such a list AND that it 
    is an error to pass such a list to someone else using APPLY and then 
    later modify it. eg,	(PROGN (APPLY #'FOO L) (SETF (CDR L) ...))
    may screw up state that FOO has encached for later use.

	I don't see why allowing the &rest list to be the same list that was
passed to apply requires any of the above suggestions about what "is an error".
Lisp functions are allowed to modify their arguments, or save them for
later use.  Proposal 13 says that APPLY, like NCONC, is such a function in
the case where the function being APPLYed does destructive operations on
its &rest argument. (apply #'rplacd args) and (apply #'foo args) both
modify their arguments if foo is a function that does destructive
operations on its &rest argument, and I don't see a big difference
between them. In general, if I write a function that destructively
modifies its arguments (or use an existing one, like NCONC), I
must be careful that no other part of the code assumes that the
structure I have modified will not change. If you use argument-modifing
functions recklessly, you will produce obscure, hard-to-find, bugs. This is
certainly true of normal arguments to functions, and I don't see why it
shouldn't be true of &rest arguments as well, particularly if it can make
some implementations more efficient.

	I also believe their should be some kind of &temp-rest lambda
list keyword that produces an &rest list with dynamic extent, but that's
a separate proposal that should be dealt with later.

Proposal #14:  THE and VALUES

	The purpose of THE is to give the compiler or interpreter
information on the type of the value(s) returned by the form, since
this may help produce more efficient code. Information on the
number of values reuturned can presumably be put to similar use.
It would be nice to have syntax to say either "These are the
types of the first two returned values, and I don't know the types
of any others, if any" or "Exactly two values will be returned, and here
are their types". (THE (VALUES type1 type2 &rest T)) and
(THE (VALUES type1 type2)) seems like as good a syntax as any
for expressing these two concepts.
	I have no strong feelings as to whether (THE type1) should
be equivalent to (THE (VALUES type1)) or (THE (VALUES type1 &rest T)).
	On the subject of VALUES, I noticed that Cltl says, on the
issue of checking the type of the value(s) returned by a form in a
THE special form, "Implementations are encouraged to make an explicit
error check when running interpretively" (P 163). It seems to me that this
check should be made if it is declared (optimize (safety 3) (speed 0)),
and should not be made if it is declared (optimize (safety 0) (speed 3)), regardless
of whether it is interpreted or compiled, and that the reference to the
interpreter should be removed.

							Andy Latto
							alatto@bbn.ARPA