Issue MULTIPLE-VALUES-LIMIT-ON-VARIABLES Writeup

```Issue:             MULTIPLE-VALUES-LIMIT-ON-VARIABLES
References:        MULTIPLE-VALUES-LIMIT,
MULTIPLE-VALUE-SETQ, MULTIPLE-VALUE-BIND,
NTH-VALUE
Related issues:    none
Category:          CLARIFICATION
Edit history:      v1, 13 Feb 1991, Sandra Loosemore

Problem description:

The constant MULTIPLE-VALUES-LIMIT is defined in CLtL as the upper
exclusive bound on the number of values that may be returned from
a function.  Does this limit also apply to the number of variables
that may be bound or assigned by MULTIPLE-VALUE-BIND or
MULTIPLE-VALUE-SETQ?  Or are the excess variables simply given values
of NIL?

There are two proposals, UNDEFINED and NIL.

Proposal (MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED):

Clarify that MULTIPLE-VALUES-LIMIT applies to the number of variables
that may be bound or assigned by MULTIPLE-VALUE-BIND or
MULTIPLE-VALUE-SETQ and the index argument to NTH-VALUE, as well
as to the number values that can actually be returned.

Rationale:

It's conceivable that these forms for accessing multiple values
could be implemented in such a way that they break if you try to
access values beyond MULTIPLE-VALUES-LIMIT.

Proposal (MULTIPLE-VALUES-LIMIT-ON-VARIABLES:NIL):

Clarify that MULTIPLE-VALUES-LIMIT applies only to the number of values
that can actually be returned, and not to the number of variables that
may be bound or assigned by MULTIPLE-VALUE-BIND or MULTIPLE-VALUE-SETQ
or the index argument to NTH-VALUE.  As usual, NIL if there are not
enough values actually returned.

Rationale:

There are ways of implementing these forms for accessing multiple
values in such a way that they don't break if you try to access
values beyond MULTIPLE-VALUES-LIMIT.

Current Practice:

I don't know.

Cost to Implementors:

For proposal UNDEFINED, none.
For proposal NIL, more care needs to be taken in implementing multiple
values.

Cost to Users:

For proposal NIL, none.
For proposal UNDEFINED, loss of portability for some programs (probably
very rare).

Confusion about what implementation techniques for multiple values are
valid.

Performance impact:

Hard to say.

Benefits:

The cost of non-adoption is avoided.

Esthetics:

Proposal NIL is probably better from a purely theoretical point of view,
since it doesn't complicate the language by imposing arbitrary limits
on programs.

Discussion:

Loosemore prefers proposal NIL, as long as it doesn't cause problems
for implementors.
-------
```