Forum: Editorial
Category: CLARIFICATION/CHANGE
Edit history: 2004-07-20, Version 1 by Bruno Haible
2004-07-19, Version 2 by Christophe Rhodes (add LAMBDA-LIST-KEYWORDS-MULTIPLE-VALUE-CALL)
Status: For CLiki consideration
- Problem Description:
- The entry for THE seems to imply that the number of values is not important. However, the entry for VALUES says that using &optional or &rest constrains the number of values.
- Proposal (THE-VALUES:MINIMAL-CLARIFY):
- Add a note to the VALUES description, reminding that THE does not complain about a wrong number of values.
- Test case:
- Rationale:
- The previous issue THE-VALUES:RETURN-NUMBER-RECEIVED is clear.
- Proposal (THE-VALUES:LAMBDA-LIST-KEYWORDS-MULTIPLE-VALUE-CALL):
- Add a note to the THE description, reminding that adding lambda list keywords to a THE VALUES type specifier implies a stronger contract on the return types: those that can be passed to MULTIPLE-VALUE-CALL without error
- Test case:
- (the (values integer &optional) (values 3 3))
- Rationale:
- The previous issue THE-VALUES:RETURN-NUMBER-RECEIVED refers only to VALUES types without lambda list keywords; it is not clear at all that the extended values types were considered by the issue writers. Without this proposal, there is no way of using THE for constraining the number of values received.
- Current practice:
- Cost to Implementors:
- Cost to Users:
- Cost of Non-Adoption:
- Benefits:
- Aesthetics:
- Discussion:
- Bruno Haible supports proposal MINIMAL-CLARIFY.
- Bruno Haible says: Proposal LAMBDA-LIST-KEYWORDS-MULTIPLE-VALUE-CALL appears to introduce a voluntary divergence between lambda lists with lambda list keywords and those without. For example, under this proposal, the type (values integer &optional) is different from the type (values integer). I'm opposed to this change, because
- in all other situations &optional at the end of a lambda list is a nop,
- it disagrees with values
- Discussion: