[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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

Cost of non-adoption:

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.

-------


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.