[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: REST-ARGUMENT-EXTENT
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: Issue: REST-ARGUMENT-EXTENT
- From: masinter.pa@Xerox.COM
- Date: 11 Apr 88 10:23 PDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM, Hornig@ALDERAAN.SCRC.Symbolics.COM, PRobertson@MEAD.SCRC.Symbolics.COM, Laddaga@MEAD.SCRC.Symbolics.COM
- In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of Sun, 10 Apr 88 18:09 EDT
I find the distinction between parameters and arguments useful enough to want to
change the name of this issue. The &REST parameter is bound to a list containing
the rest of the arguments; the issue is not the extent of the argument but
rather REST-PARAMETER-VALUE-EXTENT, or, more concicely although more
ambiguously, REST-LIST-EXTENT.
As a feature to be added to the standard, this proposal is fairly weak: it adds
an optional declaration which exists in some implementations. For
implementations that do not already have this feature, is this the "optimal"
feature to add? For example, should it instead be the case that we might allow
the rest parameter to be bound to a vector (as JonL has suggested?).
Note that there is a related issue, currently named REST-LIST-ALLOCATION, which
addresses the ambiguity over whether rest lists are shared in the case where
APPLY is used. I think we do have some obligation to resolve ambiguities in the
current specification before going on to add (optional) features.